#17 Crash on startup

closed-works-for-me
None
5
2006-04-08
2006-04-04
No

Same problems as others have reported: the window opens
(blank) and then it crashes with a segfault. Valgrind says:

==7208== Source and destination overlap in
memcpy(0x726D028, 0x706C028, 4194304)
==7208== at 0x401F5CA: memcpy (mac_replace_strmem.c:394)
==7208== by 0x40808E6: __glFillImage (in
/usr/X11R6/lib/libGL.so.1.2)
==7208== by 0x4082422: __glXSendLargeImage (in
/usr/X11R6/lib/libGL.so.1.2)
==7208== by 0x406F4A9: (within
/usr/X11R6/lib/libGL.so.1.2)
==7208== by 0x8063ADE:
TextureLoader::loadSurface(SDL_Surface*)
(textureloader.cpp:108)
==7208== by 0x80640A1:
TextureLoader::loadTexture(std::string const&,
std::string const&) (textureloader.cpp:42)
==7208== by 0x80511BE: main (brutalchess.cpp:1319)
==7208==
==7208== Invalid read of size 1
==7208== at 0x401F610: memcpy (mac_replace_strmem.c:394)
==7208== by 0x40808E6: __glFillImage (in
/usr/X11R6/lib/libGL.so.1.2)
==7208== by 0x4082422: __glXSendLargeImage (in
/usr/X11R6/lib/libGL.so.1.2)
==7208== by 0x406F4A9: (within
/usr/X11R6/lib/libGL.so.1.2)
==7208== by 0x8063ADE:
TextureLoader::loadSurface(SDL_Surface*)
(textureloader.cpp:108)
==7208== by 0x80640A1:
TextureLoader::loadTexture(std::string const&,
std::string const&) (textureloader.cpp:42)
==7208== by 0x80511BE: main (brutalchess.cpp:1319)
==7208== Address 0x726D027 is 1 bytes before a block
of size 4,194,304 alloc'd
==7208== at 0x401D422: malloc (vg_replace_malloc.c:149)
==7208== by 0x40823CA: __glXSendLargeImage (in
/usr/X11R6/lib/libGL.so.1.2)
==7208== by 0x406F4A9: (within
/usr/X11R6/lib/libGL.so.1.2)
==7208== by 0x8063ADE:
TextureLoader::loadSurface(SDL_Surface*)
(textureloader.cpp:108)
==7208== by 0x80640A1:
TextureLoader::loadTexture(std::string const&,
std::string const&) (textureloader.cpp:42)
==7208== by 0x80511BE: main (brutalchess.cpp:1319)

(full log attached; I added the blank lines when the
window appeared)

Commenting out the call to glTexImage2D makes it work
(slowly), but with no board texture.

Discussion

  • Joe Flint

    Joe Flint - 2006-04-05

    Logged In: YES
    user_id=822076

    A backtrace from GDB would be helpful in figuring out what
    is actually going on, the valgrind trace is a bit hard to read.

    What graphics card, driver, and platform are you running on?

     
  • Joe Flint

    Joe Flint - 2006-04-05
    • assigned_to: nobody --> gyrojoe
     
  • Thomas Leonard

    Thomas Leonard - 2006-04-05

    Logged In: YES
    user_id=40461

    gdb output attached, though it says much the same as valgrind.
    I'm on Linux Debian/unstable with the NVidia driver.

     
  • Thomas Leonard

    Thomas Leonard - 2006-04-05
     
  • Joe Flint

    Joe Flint - 2006-04-05

    Logged In: YES
    user_id=822076

    What card specifically are you using?
    I'm thinking that it might be caused by an unsupported
    texture size. Try cropping the textures to a smaller size
    like 256x256 and see if they will load then.

     
  • Thomas Leonard

    Thomas Leonard - 2006-04-06

    Logged In: YES
    user_id=40461

    Scaling the marble textures down to 128x128 made it work.
    Card is:

    0000:01:00.0 VGA compatible controller: nVidia Corporation
    NV11 [GeForce2 Go] (rev b2)

     
  • Joe Flint

    Joe Flint - 2006-04-06

    Logged In: YES
    user_id=822076

    Let's see what value it gives for maximum texture size. Put
    this in the code somewhere, then see what value it prints out:
    int n;
    glGetIntegerv(GL_MAX_TEXTURE_SIZE, &n);
    cout << n << endl;

     
  • Thomas Leonard

    Thomas Leonard - 2006-04-06

    Logged In: YES
    user_id=40461

    It says "2048".

     
  • Nobody/Anonymous

    Logged In: NO

    What version of X, the nVidia driver, and mesa are you using?

    Also, put this:
    cout << "glGetError(): " << glGetError() << endl;
    before and after the glTexImage2D call (and use the big
    textures)

     
  • Thomas Leonard

    Thomas Leonard - 2006-04-07

    Logged In: YES
    user_id=40461

    It looks like the problem was with software rendering. I now
    have hardware acceleration working, and it works even with
    the large textures (error codes are 0 before and after). And
    it's fast now ;-)

    Mesa is version 4.3.0.dfsg.1-14, with X.org 6.9.0.dfsg.1-4.

    Thanks,

     
  • Joe Flint

    Joe Flint - 2006-04-08
    • status: open --> closed-works-for-me
     
  • Joe Flint

    Joe Flint - 2006-04-08

    Logged In: YES
    user_id=822076

    Sounds like a bug in the software render. It shouldn't crash
    even when the texture is too big, but should return an error
    instead. Anyway, problem solved.

     

Log in to post a comment.