osgViewer crashes at inserting string into stream inside Renderer::draw() (Win10, osg3.2.0, compiler vc10)

[Yuan Cheng]

Hello everyone,

recently I encountered a sporadic crash in my App at same position upon calling function Renderer::draw() in osgViewer/Renderer.cpp. The crash happend at 

  DEBUG_MESSAGE<<"draw() got SceneView "<<sceneView<<std::endl; (screenshots of callstack are attached)

 

and triggerd an exception via a string of basic streambuf operations very deep down to msvcp100d.dll in dbgheap.c

         /*

         * If this ASSERT fails, a bad pointer has been passed in. It may be

         * totally bogus, or it may have been allocated from another heap.

         * The pointer MUST come from the 'local' heap.

         */

        _ASSERTE(_CrtIsValidHeapPointer(pUserData));  ----> assertion error thrown, the heap pointer is invalid

In debug session I checked the call stack step by step and found that when putting "draw() got SceneView" in stringbuffer, functoin overflow of std::basic_stringbuf is triggerd, and subsequently

the deallocate step at :

                        if (_Mystate & _Allocated)

_Al.deallocate(_Oldptr, _Oldsize);

_Mystate |= _Allocated;

was executed. it tried to deallocate the buffer, pointed by "_Oldptr" with size "_Oldsize". But the size is smaller than the actual buffer length. Therefore the assertion error above was thrown.

Info to my App:

I enhance the viewer with osgWidget::WindowManager. My App recieves external data cyclic and renders boxes and lines in one data transmission framework. The API of this framework calls my viewer to render every 20ms, an example of this call:

   framework::call_on_cycle () {  // main thread

                   // process and storing incoming data

                   process_data();

                   myViewer->frame();

 }

 

My App runs at DrawThreadPerContext mode and updates drawables in callback and setting them as DYNAMIC.

Is there anyone ever facing similar Problem? Or any ideas to analyse or sort this out? I will really appreciate any help.

Thank you

Regards,

Yuan

[Robert Osfield]

Hi Yuan,

I'm not a Windows users so can't comment on platform specifics, so have to take an guess, could it be thread safety issue with the Windows iostream implementation? 

Could you try with the Viewer threading set to SingleThreaded to see if it's related to threading.

Could you also disable the debug console output to see if that addresses the problem?

Robert.

[Yuan Cheng]

Hi Robert,

thank you for the reply. You guess point me out to some way I could do further problem analysis. 

 1.could it be thread safety issue with the Windows iostream implementation?   - that is a valid point I will check out this.

 2.SingleThreaded to see if it's related to threading -  I have tried this, app does not crash as far as I have tested.

 

 3.disable the debug console output - do you mean by disable this marco DEBUG_MESSAGE?  I noticed a macro "OSG_NOTIFY_DISABLED" in include/osg/Notify. Shoud I just define this in that file Notify?

 Best Regards

 Yuan

[L. Voerman]

Hi Yuan,

I created a workaround for this problem on 22 Aug 2017 titled "reduce the need to reallocate the std::ostream buffer behind osg::Notify..." - link: https://github.com/openscenegraph/OpenSceneGraph/pull/314

As it's only a few lines, I guess backporting to 3.2 will be rather simple.

Regards, Laurens.

[Yuan Cheng]

Hi Laurens,

thank you so much. I will have a look at your post and try it out. I think that will solve this problem :) 

Best regards

Yuan

[OpenSceneGraph Users]

Hi Yuan,

On Wed, 18 Mar 2020 at 16:25, OpenSceneGraph Users <osg-...@lists.openscenegraph.org> wrote:

Hi Yuan,

I created a workaround for this problem on 22 Aug 2017 titled "reduce the need to reallocate the std::ostream buffer behind osg::Notify..." - link: https://github.com/openscenegraph/OpenSceneGraph/pull/314

As it's only a few lines, I guess backporting to 3.2 will be rather simple.

3.2 was released 7 years ago There are hundreds of improvements since 3.2.

We could waste a lot of time trying to help you with long fixed problems without knowledge that you are using and old version.  What about just moving to 3.6.x.  I strongly recommend that you move onto a version that we can support properly.

Cheers,

Robert.

 

 

[Yuan Cheng]

Hi Robert,

you are right about that. In my position I would like to use 3.6x. Unfortunately my App is restricted to that old osg due to some project releated reasons. Thank you all the same.

Regards

Yuan