Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: [solved] sf::String::Text, memory access violation (read)  (Read 3975 times)

0 Members and 1 Guest are viewing this topic.

resident-uhlig

  • Newbie
  • *
  • Posts: 2
    • View Profile
[solved] sf::String::Text, memory access violation (read)
« on: March 12, 2009, 11:18:43 pm »
Hello all.

I have some problems using sf::String/sf::Unicode::Text in my project. After some hours trying and searching the internet to get it working I am very desperate else I would not have created this thread.

This is my development environment:
SFML 1.4
Code::Blocks 8.02 (mingw)
Windows XP SP3 (en)

So basicly I want to use a new sf::Unicode::Text to fill a new sf::String:
Code: [Select]
sf::String        test( sf::Unicode::Text( "42" ) );

The problem is that I get a memory access violation (read) in this line. I got two solutions for this:
    [*] use L"42" instead
    [*] log in as Administrator
    [/list]

    The first one is not acceptable because I have cases in which I only have a char and not a wchar. The second one is not accapteble because I don't want to ask my users of my software to be logged in as Administrator.

    Then there is another problem. Even if I get the line above working I will get another memory access violation (read) when the program exits. For this I did not find a solution. This is very simple code that will raise this error aswell:
    Code: [Select]
    int main() { sf::String a; return 0; }

    Both problems seem to have something to do with this DLL: nvoglnt.dll
    That's what I can read from the debugger:
    Quote
    Program received signal SIGSEGV, Segmentation fault.
    In nvoglnt!DllMain () (C:\WINDOWS\system32\nvoglnt.dll)


    Here are some references that might fit to my problem but without a working solution:
      [*] SFML Forum: Error When Closing Window
      [*] SFML Forum: Small bug
      [*] Foreign forum: Tackeling segmentation fault (nasty bug is ruining my game)
      [/list]

      Hope you can help me,
      resident-uhlig.

      Laurent

      • Administrator
      • Hero Member
      • *****
      • Posts: 32498
        • View Profile
        • SFML's website
        • Email
      [solved] sf::String::Text, memory access violation (read)
      « Reply #1 on: March 13, 2009, 07:52:54 am »
      The first bug has been fixed, you can try getting the latest sources and recompiling SFML to get the fix.

      The second one, as you probably noticed, will be fixed in SFML 2.0.
      Laurent Gomila - SFML developer

      Laguna

      • Newbie
      • *
      • Posts: 11
        • View Profile
      [solved] sf::String::Text, memory access violation (read)
      « Reply #2 on: March 13, 2009, 08:41:12 am »
      - Try updating yout nVidia Drivers (nvoglnt.dll is responsible for nvidia <-> OpenGl )

      - Initialize Strings like this (works fine for me)
      Code: [Select]

      sf::Font arial;
      arial.LoadFromFile("arial.ttf", 32 );
       sf::String ("bla", arial)

      whereas font is NOT the default font.

      - Use Static linked version of SFML (works fine for me)

      Tank

      • SFML Team
      • Hero Member
      • *****
      • Posts: 1486
        • View Profile
        • Blog
        • Email
      [solved] sf::String::Text, memory access violation (read)
      « Reply #3 on: March 13, 2009, 02:41:35 pm »
      @Laguna:
      So can using the default font cause errors? Maybe normal users in WinXP are not allowed to load the proper font?
      If that's the case, SFML should be more verbose about that.

      @Laurent:
      Is the first fix included in the SFML 2.0 branch? And when do you think will be the second one applied to SVN? It's a really annoying thing.

      Laurent

      • Administrator
      • Hero Member
      • *****
      • Posts: 32498
        • View Profile
        • SFML's website
        • Email
      [solved] sf::String::Text, memory access violation (read)
      « Reply #4 on: March 13, 2009, 02:56:53 pm »
      Quote
      So can using the default font cause errors? Maybe normal users in WinXP are not allowed to load the proper font?
      If that's the case, SFML should be more verbose about that.

      No. In fact it has something to do with destroying the OpenGL texture owned by the font at global exit. Probably an issue regarding contexts lifetime (even though SFML is supposed to be safe in this regard...).

      Quote
      Is the first fix included in the SFML 2.0 branch?

      No, it's in the trunk (SFML 1.5).

      Quote
      And when do you think will be the second one applied to SVN? It's a really annoying thing.

      I've almost finished rewriting OpenGL contexts handling, and hopefully the bug will vanish after that.
      Laurent Gomila - SFML developer

      resident-uhlig

      • Newbie
      • *
      • Posts: 2
        • View Profile
      [solved] sf::String::Text, memory access violation (read)
      « Reply #5 on: March 13, 2009, 05:08:18 pm »
      Hello all!

      Thank you for your help, Laurent, Laguna and Tank.

      Laurent's recommendation was the solution:
      Quote from: "Laurent"
      The first bug has been fixed, you can try getting the latest sources and recompiling SFML to get the fix.


      After downloading SFML 1.5 (SVN: trunk/) and building the libs on my own the first problem is solved.

      Though the second one still exists but I think I can live with that because it only happens on program exit and as mentioned by Laurent it will get a fix in SFML 2.

      Driver update and loading a font before did not help, btw.

      Best regards,
      resident-uhlig.

      Tank

      • SFML Team
      • Hero Member
      • *****
      • Posts: 1486
        • View Profile
        • Blog
        • Email
      [solved] sf::String::Text, memory access violation (read)
      « Reply #6 on: March 13, 2009, 06:21:04 pm »
      Quote from: "Laurent"
      Quote
      Is the first fix included in the SFML 2.0 branch?

      No, it's in the trunk (SFML 1.5).

      Don't forget to put it into SFML2, too. ;)

      Quote
      I've almost finished rewriting OpenGL contexts handling, and hopefully the bug will vanish after that.

      Great, thanks for the info.

       

      anything