#41 St9bad_alloc

Build issue
closed-SEP
DRC
VirtualGL (44)
5
2014-03-28
2012-02-26
Ingo Theiss
No

Hi,

I am getting the following error more or less randomly when running the game Skyrim through wine. Is this error related to VirtualGL or wine?
Here is the end from the output while running with \'+v +tr\' option:

...
[VGL] glDrawBuffer (mode=0x00008ce0 pbw->_dirty=0 pbw->_rdirty=0 pbw->getglxdrawable()=0x00e00008 ) 0.000000 ms
[VGL] glFlush()
[VGL] glViewport (x=0 y=0 width=480 height=300 ) 0.000000 ms
[VGL] glFlush()
[VGL] glViewport (x=0 y=0 width=480 height=300 ) 0.000000 ms
[VGL] glFlush()
[VGL] glViewport (x=0 y=0 width=480 height=300 ) 0.000000 ms
[VGL] glFlush()
[VGL] glViewport (x=0 y=0 width=1920 height=1200 ) 0.000000 ms
[VGL] glFlush()
[VGL] glViewport (x=0 y=0 width=1920 height=1200 ) 0.000000 ms
[VGL] glDrawBuffer (mode=0x00000405 pbw->_dirty=0 pbw->_rdirty=0 pbw->getglxdrawable()=0x00e00008 ) 0.000000 ms
[VGL] glViewport (x=0 y=0 width=1920 height=1200 ) 0.000000 ms
[VGL] glFlush()
[VGL] glFlush()
[VGL] glFinish()
[VGL] glXSwapBuffers (dpy=0x7dfad6f8(localhost:10.0) drawable=0x03800002 [VGL] ERROR: in init--
[VGL] 493: St9bad_alloc

[VGL] glXDestroyPbuffer (dpy=0x7dfa1658(:0.0) pbuf=0x00e00008 ) 0.000000 ms
[VGL]
[VGL] glXDestroyPbuffer (dpy=0x7dfa1658(:0.0) pbuf=0x00e00004 ) 0.000000 ms
[VGL]
[VGL] glXDestroyPbuffer (dpy=0x7dfa1658(:0.0) pbuf=0x00e00006 ) 0.000000 ms

The screen freezes and I have to kill the programm on the server side. I am not getting any core dump.

Thanks for your time!

Regards,

Ingo

Discussion

  • Ingo Theiss

    Ingo Theiss - 2012-02-26

    vglrun +v +tr

     
  • DRC

    DRC - 2012-03-09

    I need to know the exact version you are running to correlate where that error message is occurring in the code (the "493" part is a line number.) I suspect that it's coming from the Pbuffer creation code, so it may indicate some sort of error with creating a Pbuffer. What graphics card and driver revision are you using? Are you able to run other 3D apps in VirtualGL without using WINE (/opt/VirtualGL/bin/glxspheres, for instance?)

     
  • DRC

    DRC - 2012-03-09

    Googling for St9_badalloc, it seems to be related to memory exhaustion. Can you monitor the WINE process using top or some similar tool and make sure it isn't leaking? If it appears to be, then monitor a non-WINE process (such as GLXspheres) in VirtualGL to determine whether the leak is WINE's fault or ours. If VirtualGL had a leak, someone would've reported it by now, so I suspect it's WINE's fault, or maybe the 3D application's fault.

     
  • Ingo Theiss

    Ingo Theiss - 2012-03-12

    I am running VirtualGL on my Debian AMD64 box and installed your official deb´s
    VirtualGL_2.3_amd64.deb and VirtualGL32_2.3_amd64.deb. My graphics card is a NVIDIA GeForce GTX 580 with Nvidia driver revision 295.20.
    I can run other 3D apps with or without wine without problems. The St9_badalloc error appears more or less randomly during game play with this single game (Skyrim).

    I will monitor wine and glxspheres and report to you.

     
  • Ingo Theiss

    Ingo Theiss - 2012-03-20

    Ok here are observations.

    Monitoring glxspheres didn´t reveal any memory leaks. Regarding WINE and I can´t tell for sure if it leaking or not.

    Some research about the possible sources of St9bad_alloc sowed the following conclusion:

    ---
    When new fails to allocate the memory for an object, or new[] fails to allocate the memory for an object array, a std::bad_alloc object is thrown. In GCC, the RTTI mangled name of std::bad_alloc is St9bad_alloc.
    ---

    This error is driving me nuts. It happens at random. Sometimes after only 30 seconds, sometimes 5 minutes or sometimes I notging happens for 30 minutes.

    My box has 8 GB of RAM and there is plenty of free memory available, when the error occurs.

    Regarding the possible sources of St9bad_alloc it seems to me the problem is comming from the VirtualGL source. Where you able to find the line number and maybe the "bad" new which causes the error.

     
  • DRC

    DRC - 2012-03-20

    The error is occurring in rrframe.h, but I have no clue what could be causing it. It occurs when trying to allocate an output buffer for JPEG encoding:

    newcheck(_bits=new unsigned char[TJBUFSIZE(h.width, h.height)]);

    (newcheck() is a macro that is catching the std::badalloc exception, and that is where the St9bad_alloc message comes from.)

    My best suggestion would be to build VirtualGL 2.3 from source and add a print statement prior to line 493 in rrframe.h and see what the value of h.width, h.height, and TjBUFSIZE(h.width, h.height) are. Maybe for some bizarre reason, they are 0, although I can't fathom how that could happen without an error being tripped much earlier in the execution.

     
  • Ingo Theiss

    Ingo Theiss - 2012-03-20

    You mentioned "..trying to allocate an output buffer for JPEG encoding".
    I am using rgb or yuv compression type. Is your conclusion still correct with these compression types? Or am I mixing things up right now?

    I will build VirtualGL from source and add the print statement as you suggested.

     
  • DRC

    DRC - 2012-03-20

    That same line of code is used to allocate any output frame when using the VGL Transport, so it would be used with RGB and YUV as well.

    However, now I am curious as to whether you can reproduce this same failure when using JPEG or whether it's specific to RGB or YUV encoding. Also, have you tried using the X11 Transport, either with or without TurboVNC? Curious as to whether it's reproducible there as well.

    Since I have no access to the game in question, I have no way to reproduce the specific failure, so my only hope here is to reproduce it outside of the game, and in order to do that, I would need some insight into what may be causing it. That's why I need you to help collect all of these datapoints.

     
  • Ingo Theiss

    Ingo Theiss - 2012-03-22

    Ok, here we go. I have done what you requested but I fear things getting more complicated than before. Please see attached trace (rrframe.txt) with the print statements I have added to rrframe.h. The print statements show up in the trace, but when the St9bad_alloc happens they are not printed. Thats crazy or I simply don´t understand whats happening.

    This is the modified part from rrframe.h I´ve added the print statements in every switch case to be sure :-)

    ---
    switch(buffer)
    {
    case RR_LEFT:
    if(h.width!=_h.width || h.height!=_h.height || !_bits)
    {
    rrout.print("\n!----- DEBUG START ----- !\n");
    rrout.print("switch(buffer) RR_LEFT:\n");
    rrout.print("h.height = %d\n", h.height);
    rrout.print("h.width = %d\n", h.width);
    rrout.print("TJBUFSIZE(h.width, h.height) = %d\n", TJBUFSIZE(h.width, h.height));
    rrout.print("!----- DEBUG END ----- !\n");

    if(_bits) delete [] _bits;
    newcheck(_bits=new unsigned char[TJBUFSIZE(h.width, h.height)]);
    }
    _h=h; _h.flags=RR_LEFT; _stereo=true;
    break;
    case RR_RIGHT:
    if(h.width!=_rh.width || h.height!=_rh.height || !_rbits)
    {
    rrout.print("\n!----- DEBUG START ----- !\n");
    rrout.print("switch(buffer) RR_RIGHT:\n");
    rrout.print("h.height = %d\n", h.height);
    rrout.print("h.width = %d\n", h.width);
    rrout.print("TJBUFSIZE(h.width, h.height) = %d\n", TJBUFSIZE(h.width, h.height));
    rrout.print("!----- DEBUG END ----- !\n");

    if(_rbits) delete [] _rbits;
    newcheck(_rbits=new unsigned char[TJBUFSIZE(h.width, h.height)]);
    }
    _rh=h; _rh.flags=RR_RIGHT; _stereo=true;
    break;
    default:
    if(h.width!=_h.width || h.height!=_h.height || !_bits)
    {
    rrout.print("\n!----- DEBUG START ----- !\n");
    rrout.print("switch(buffer) default:\n");
    rrout.print("h.height = %d\n", h.height);
    rrout.print("h.width = %d\n", h.width);
    rrout.print("TJBUFSIZE(h.width, h.height) = %d\n", TJBUFSIZE(h.width, h.height));
    rrout.print("!----- DEBUG END ----- !\n");

    if(_bits) delete [] _bits;
    newcheck(_bits=new unsigned char[TJBUFSIZE(h.width, h.height)]);
    }
    _h=h; _h.flags=0; _stereo=false;
    break;
    }

    ---

    Until now I was not able to reproduce the problem with JPEG encoding. But I will test this further. I will look at X11 Transport in the next days.

     
  • Ingo Theiss

    Ingo Theiss - 2012-03-22

    I am unable to upload the trace I mentioned. Always getting the following error from sourceforge: "File upload: ArtifactFile: Could not open file for writing"

    Any idea how to attach the file?

     
  • DRC

    DRC - 2012-03-22

    It may be too big. e-mail it to me.

     
  • Ingo Theiss

    Ingo Theiss - 2012-03-23
     
  • Ingo Theiss

    Ingo Theiss - 2012-03-23

    Upload succeed this morning from workplace. Filename is rrframe.txt.
    I am curious what you say why the debug output is not getting printed when the St9bad_alloc happens.

     
  • DRC

    DRC - 2012-03-23

    The only reason I can think of is that maybe the stream isn't being flushed prior to the error. Try using rrout.PRINTLN (all caps, which flushes the stream as well as printing) for the last debug statement right before newcheck().

     
  • Ingo Theiss

    Ingo Theiss - 2012-03-24

    Finally I´ve managed to get the desired output.

    I had to rewrite the newcheck(_bits=new unsigned char[TJBUFSIZE(h.width, h.height)]); part in rrframe.h in order to get the print statements in case of the exception. I hope that I did it right. The output is behind the snipplet.

    ---
    default:
    if(h.width!=_h.width || h.height!=_h.height || !_bits)
    {
    if(_bits) delete [] _bits;
    //newcheck(_bits=new unsigned char[TJBUFSIZE(h.width, h.height)]);

    try {
    _bits=new unsigned char[TJBUFSIZE(h.width, h.height)];
    }
    catch(std::bad_alloc& e)
    {
    printf("\n!----- DEBUG START ----- !\n");
    printf("switch(buffer) default:\n");
    printf("h.height = %d\n", h.height);
    printf("h.width = %d\n", h.width);
    printf("TJBUFSIZE(h.width, h.height) = %d\n", TJBUFSIZE(h.width, h.height));
    printf("!----- DEBUG END ----- !\n");

    printf(e.what());
    }

    }
    _h=h; _h.flags=0; _stereo=false;
    break;
    ---

    Here is the output:

    !----- DEBUG START ----- !
    switch(buffer) default:
    h.height = 1200
    h.width = 1920
    TJBUFSIZE(h.width, h.height) = 13826048
    !----- DEBUG END ----- !
    std::bad_alloc

    I think that is pretty ok, or? Anything else I could check?

     
  • DRC

    DRC - 2012-03-25

    Those are correct values, so I'm still not sure why the exception is thrown by new. I really do not think it's a VirtualGL bug. VirtualGL is being used by thousands of people with thousands of different apps, including lots of games run in WINE, and this is the only instance of this particular issue that has been reported. That being said, this may be an "interaction issue"-- that is, the game may be doing something that it really shouldn't, and that's causing problems with VirtualGL that need to be worked around.

    Have you tried valgrind to see if there are any memory leaks? I also really need to know whether this also occurs with JPEG encoding or the X11 transport.

     
  • DRC

    DRC - 2012-03-25

    It might also be fruitful to try removing the try/catch block in newcheck() to see if this causes the failure to manifest itself in a different way, which may give us further clues as to what's happening.

     
  • Ingo Theiss

    Ingo Theiss - 2012-03-26

    Here are the next results. The error occurs also with JPEG encoding. Will try to get valgrind running and see what I can get. I think you are rigth and the error is more likly a problem of wine or the game itself, which is got for you and the rest of the users :-)

     
  • DRC

    DRC - 2012-03-26

    Where are the next results? Did you try removing the try/catch block? What happened?

     
  • DRC

    DRC - 2012-05-25

    Any word on this?

     
  • Ingo Theiss

    Ingo Theiss - 2012-05-30

    Hi,

    sorry for not responding a long time. I haven´t much time to investigate this problem any further. With the latest Wine Version 1.5.5 the problem is still there but happens very very seldom. Any other games I am playing with Wine an VirtualGL are not showing this error.

    I am closing this report as the problem it is not steady repeatable and only a single game is affected.

    Thanks for your support!

     
  • Ingo Theiss

    Ingo Theiss - 2012-05-30
    • status: open --> closed
     
  • DRC

    DRC - 2014-03-28
    • status: closed --> closed-SEP
    • Group: --> Build issue
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks