Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi all, I don't know if anyone was interested in this issue, but after a few more back-and-forths with the NVidia developers, we were able to determine that the bug is completely fixed. I asked what the cause was, and here was their answer: There was a bug in our driver that had a race condition when an opengl thread gets destroyed. It could cause other opengl threads to deadlock. It appears the osgviewer.exe application doesn't simply create threads when the 'a' key is pressed, but it also destroys threads too. I haven't investigated what the threads do exactly, but it would appear each time 'a' is pressed, existing threads are completed and new ones (including the extra one) are recreated. It's when these threads are completed that the race condition could be hit. Also increasing the chances of this problem being hit, is how quickly and how many threads are completed at once. For this application, each time 'a' is pressed, a larger and larger number of threads are completed, increasing the chance of deadlock. The bug was fixed by resolving the race condition that existed when an opengl thread is completed. That got me thinking about the need for stopThreading() before adding a view... They seem to say that we could create a graphics context and related graphics thread without stopping existing threads in the viewer. Perhaps I'll investigate that in the near future. I also asked whether the bug was resolved in the Linux drivers, and here was the answer: As for whether or not your issue in Linux was resolved, I can't say for sure because we didn't have immediate access to a system to spend time testing it on, but it should be the same cause, and as such we believe it should be fixed there too. If you find it isn't resolved with the same version numbers the fix was seen in for Windows (182.06 or higher), let us know. That would seem to indicate that at least some of their driver code is common between platforms, which is interesting in light of the driver quality discussions we had lately. Robert, I don't know how often you can update your graphics drivers, but I'd certainly be interested to see if the issue is resolved on your Linux machine with the most recent drivers (if 182.06). If you don't have the example code that reproduced the deadlock, I can resend it. Anyways, in our application the issue is indeed gone, so that's good news for us. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi JS, Thanks for the update, and info about the bug fix from NVidia. Kudos to yourself and NVidia for getting this one put to bed. On Tue, Apr 7, 2009 at 5:41 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Robert, I don't know how often you can update your graphics drivers, but I'd certainly be interested to see if the issue is resolved on your Linux machine with the most recent drivers (if 182.06). If you don't have the example code that reproduced the deadlock, I can resend it. We'll right now I'm working on ATI graphics card ;-) A quick check of the Ubunutu repositories suggest that leatest NVidia drive available is 180.44, this is latest driver up on NVidia's linux web page as well. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, We'll right now I'm working on ATI graphics card ;-) Booo :-) I'm sure this is very low on your priority list, but any chance you'll get the stats handler's GPU time to show up on ATI cards? :-) A quick check of the Ubunutu repositories suggest that leatest NVidia drive available is 180.44, this is latest driver up on NVidia's linux web page as well. Hmmm, ok so we'll have to wait. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Tue, Apr 7, 2009 at 6:30 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: We'll right now I'm working on ATI graphics card ;-) Booo :-) I'm sure this is very low on your priority list, but any chance you'll get the stats handler's GPU time to show up on ATI cards? :-) Does ATI support any GPU query extensions? The OSG code is not specific to NVidia. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, Does ATI support any GPU query extensions? The OSG code is not specific to NVidia. It seems that it doesn't support those extensions, no (note that I haven't looked at it specifically, just relying on the effect which is that the GPU time line is missing in the stats handler). Even if it doesn't support those extensions, I'm sure it must support something similar, but perhaps it's a vendor extension. I'd have to look into it, but I just thought since you have an ATI card running right now :-) Don't worry, I wasn't actually asking for anything, just joking, but it's certainly the first thing I notice when I run OSG on a machine with an ATI card. Hey, there's a line missing in my stats display! J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Robert Osfield wrote: On Tue, Apr 7, 2009 at 6:30 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com mailto:jean-sebastien.g...@cm-labs.com wrote: We'll right now I'm working on ATI graphics card ;-) Booo :-) I'm sure this is very low on your priority list, but any chance you'll get the stats handler's GPU time to show up on ATI cards? :-) Does ATI support any GPU query extensions? The OSG code is not specific to NVidia. This one looks promising: AMD_performance_monitor http://www.opengl.org/registry/specs/AMD/performance_monitor.txt --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Tue, Apr 7, 2009 at 7:16 PM, Jason Daly jd...@ist.ucf.edu wrote: This one looks promising: AMD_performance_monitor http://www.opengl.org/registry/specs/AMD/performance_monitor.txt Thanks for link. Does look like it may well do the trick. I'll have to dive in fully really know how straight forward it would be. Don't have the spare time to do it right now though. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, GL_EXT_timer_query extension is the vendor independent extension, it just that AMD has clearly gone a different route. Well, it's vendor independent but only NVidia implements it. ;-) It could as well be an NV extension, no one else supports it (not just ATI/AMD, but no one else). Even if it means supporting other extensions, I think it would be good to have complete stats support not only on NVidia cards, but on others as well. Anyways, I don't have time to do anything about it, so it's just wish list item for now. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, It seems that it doesn't support those extensions, no (note that I haven't looked at it specifically, just relying on the effect which is that the GPU time line is missing in the stats handler). GLView tells me that according to its database, only NVidia cards (GeForce and Quadro - oh and S3 Chrome but who cares? :-) ) support the GL_EXT_timer_query extension. Perhaps the GPU stats could be implemented with another extension. I'd have to go through the extension list to see if there's a vendor independent extension that could do the trick. Barring that, perhaps Jason's suggestion might work too. A job for a rainy day, perhaps... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi all, Some progess on this issue, at last! Quoting myself: I might try submitting the modified example to nvidia to see if they can confirm a bug. I sent a bug report to nvidia a little while back, and got an answer last Friday saying that with the newest drivers, they could only reproduce the problem about one in 5 times. I tried these new drivers (182.06+) and they do in fact seem to fix the problem almost completely. In my case, out of about 20 tries I could only reproduce the deadlock once. So it's pretty clear it was a driver bug, and we got lucky that some other change also fixed our problem by side effect. I've asked them to check the Linux drivers too. For reference, if someone ever needs to send a driver bug report, I sent to (devsupport at nvidia dot com) and am quite happy with the turnaround time, considering I didn't have much hope of getting any answer at all... I didn't even need to be a registered developer. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi JS, On Tue, Jan 13, 2009 at 7:01 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Have you had any time to look into this? (I'm doing some gentle poking from time to time, but my goal is just to follow up, not to try and affect your priorities in any way...) I couldn't find the cause or any workaround. I tried a range of things to try and characterise and track down the cause of bug but came away without any better idea then when I started. In osgViewer/View.cpp I implemented proper setup of the number of context supported by the scene which was one bug, but this didn't effect the crash we are seeing with many contexts open. I don't know what else to try on the OSG side, and suspect a driver bug. A different tack completely would be to use SingleThreaded and implement swap groups so that all the windows swap at the same time. This would like fix the performance issues and avoid problems with thrashing the drivers so hard. For your particular usage model the only reason that you are using threading is that the driver is swapping on each swap call sequentially, not that you have multiple GPU's that you want to drive multi-threaded. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, I couldn't find the cause or any workaround. I tried a range of things to try and characterise and track down the cause of bug but came away without any better idea then when I started. In osgViewer/View.cpp I implemented proper setup of the number of context supported by the scene which was one bug, but this didn't effect the crash we are seeing with many contexts open. I don't know what else to try on the OSG side, and suspect a driver bug. That's a shame. I might try submitting the modified example to nvidia to see if they can confirm a bug. By coincidence, I just recently read their developer FAQ, and they say they generally don't need the source, just a sample application they can run to replicate the problem (I guess they run debug drivers and can trace through what the driver is doing). http://developer.nvidia.com/object/General_FAQ.html#G1 __ If the reference rasterizer results differ from the HAL results, then please get in touch with us. We will fix the problem as soon as possible. However, we will need the following information: * Operating system * Driver version * Graphics card * A sample application that clearly demonstrates the problem. We do not need source in general, and we are happy with reasonable complex apps (i.e., no need to narrow the problem down as long as the problem is clearly demonstrated). What is most important is that the problem is easy to reproduce, and that the application is self-contained. An application that goes straight to the problem is best (i.e., a single-click application that doesn't require navigation to get to the problem). __ A different tack completely would be to use SingleThreaded and implement swap groups so that all the windows swap at the same time. This would like fix the performance issues and avoid problems with thrashing the drivers so hard. For your particular usage model the only reason that you are using threading is that the driver is swapping on each swap call sequentially, not that you have multiple GPU's that you want to drive multi-threaded. Hmmm, I'll have to look around for information on swap groups. But won't my cull/draw performance be lower in SingleThreaded for large scenes, since OSG won't overlap the cull of frame n-1 with the draw of frame n? Thanks for looking into this. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi JS, On Wed, Jan 14, 2009 at 2:19 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: I might try submitting the modified example to nvidia to see if they can confirm a bug. By coincidence, I just recently read their developer FAQ, and they say they generally don't need the source, just a sample application they can run to replicate the problem (I guess they run debug drivers and can trace through what the driver is doing). http://developer.nvidia.com/object/General_FAQ.html#G1 __ If the reference rasterizer results differ from the HAL results, then please get in touch with us. We will fix the problem as soon as possible. However, we will need the following information: * Operating system * Driver version * Graphics card * A sample application that clearly demonstrates the problem. We do not need source in general, and we are happy with reasonable complex apps (i.e., no need to narrow the problem down as long as the problem is clearly demonstrated). What is most important is that the problem is easy to reproduce, and that the application is self-contained. An application that goes straight to the problem is best (i.e., a single-click application that doesn't require navigation to get to the problem). __ One could try just automatically add the views one by one to see if you it can be reproduces without any user interaction. Hmmm, I'll have to look around for information on swap groups. But won't my cull/draw performance be lower in SingleThreaded for large scenes, since OSG won't overlap the cull of frame n-1 with the draw of frame n? One could still do multi-threaded if one shared a single GraphicsThread between the various graphics contexts. This isn't supported by the viewer's threading setup right now but the underlying classes can handle it. The other way to do tackle this type of usage model would be to have all the cameras share a single GraphicsWindow and have the OSG manage the various views. This is likely to produce the best performance and scalability, having all these separate graphics contexts really isn't good for the driver or the graphics hardware. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, The other way to do tackle this type of usage model would be to have all the cameras share a single GraphicsWindow and have the OSG manage the various views. This is likely to produce the best performance and scalability, having all these separate graphics contexts really isn't good for the driver or the graphics hardware. I don't think that would work. We're using Qt as our GUI toolkit, and as far as I know we need a unique HWND for each view in order to attach that to a Qt widget. The goal is to be able to create new views at runtime, and preferably to have little limitations to the number of views the user can create. Think of a modeling application where the user can split and arrange their graphics window any way they like, and also create new graphics windows to place on other monitors and split them as well. Each view needs a unique HWND because they're all Qt widgets - the splits are managed by Qt instead of OSG. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, I might try submitting the modified example to nvidia to see if they can confirm a bug. Can I get your system stats (CPU, GPU, driver version, kernel perhaps, anything else you think is relevant) please? Just so I can quote the exact Linux system on which this was reproduced. Thanks, J-S-- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Wed, Jan 14, 2009 at 5:20 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Can I get your system stats (CPU, GPU, driver version, kernel perhaps, anything else you think is relevant) please? Just so I can quote the exact Linux system on which this was reproduced. Distro: Kubuntu 8.10, 64bit Relevant glxinfo: server glx vendor string: NVIDIA Corporation server glx version string: 1.4 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 8800 GTS/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 177.82 OpenGL shading language version string: 1.20 NVIDIA via Cg compiler g++ --version g++ (Ubuntu 4.3.2-1ubuntu11) 4.3.2 uname -r 2.6.27-9-generic Intel Quad Core i7 920, 6GB, Gefore 8800 GTS. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, I've just run it on my new machine and after a the fourth 'a' the application hangs. So I'm finally able to reproduce the bug. I've spent a bit of time in gdb but haven't got any clues yet as to the cause. Have you had any time to look into this? (I'm doing some gentle poking from time to time, but my goal is just to follow up, not to try and affect your priorities in any way...) Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, (if it didn't break threading I'd really change that subject line, others have tested and have reproduced the issue on Linux so it's not Windows-specific...) Whether the new system will work properly right away and if to does will it reproduce the hang I don't know untill I get to testing, but test it I will. OK, I'm anxiously awaiting any new info. Sorry to bother you, but have you had a chance to test my modified osgcompositeviewer example on your new machine? We really need a spot of luck (if we can call it luck) that you'll be able to reproduce the issue on *any* machine, so you can see it and maybe suggest what is causing it. It's a pretty big issue for our app, since it deadlocks after creating a few new views at runtime... Thanks in advance for any help you can provide, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi J-S, On Thu, Dec 18, 2008 at 2:41 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Sorry to bother you, but have you had a chance to test my modified osgcompositeviewer example on your new machine? No, not up to you bothered me again :-) I've just run it on my new machine and after a the fourth 'a' the application hangs. So I'm finally able to reproduce the bug. I've spent a bit of time in gdb but haven't got any clues yet as to the cause. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, I've just run it on my new machine and after a the fourth 'a' the application hangs. So I'm finally able to reproduce the bug. I've spent a bit of time in gdb but haven't got any clues yet as to the cause. I don't think I've ever been happier to have someone tell me that a program I sent them hangs... ;-) Whenever you want to put aside a little time and dig deeper, let me know. I know we can't expect anything before the holidays, so no real rush, but we'd really like to get to the bottom of this. Thanks a lot, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi J-S,
It's interesting that opening up the windows at the start allows
things to run, this suggest that it's allocation of new OpenGL that is
problem - which is something that the resize of the GL buffers would
have done the trick.
W.r.t opening 40 windows and the app crashing - this is almost
certainly down to exhustion of OpenGL resouces.
W.r.t my machine build - I have the memory here already (6GB tripple
channel), and will be reusing a case/power supply and Gfx cards from
another machine, but the key components - the CPU and the motherboard
still haven't arrived. They should arrive today or tomorrow. Can't
wait to put it together. Bit nervous about whether Linux + Gfx
drivers will install without problems, the quality of an early
motherboard bios also is a concern...
Whether the new system will work properly right away and if to does
will it reproduce the hang I don't know untill I get to testing, but
test it I will.
Robert.
On Mon, Nov 24, 2008 at 7:55 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
Hi Robert,
I've had a bit of time to look at this again today. Here's another
interesting find: adding views at startup works fine. I can add over 30 of
them (I couldn't get to 40, the program crashes, I presume because of
exhaustion of OpenGL resources or something).
Here's a modified osgviewer.cpp which demonstrates this.
program --create 20
The default is to create a single view. Starting it up with a single view
and then pressing 'a' at run time will make the program block after 4 to 6
views for me. So there's something there.
I also tested adding views after viewer.realize() but before viewer.run(),
and this seems to work too. You can specify when to create the views
(default is beforeRealize):
program --create 20 --beforeRealize
or
program --create 20 --afterRealize
Both work for me.
So there's something going on while the viewer is running that causes the
deadlock to occur if we add views at runtime. Adding them at any time before
viewer.run() seems to work fine.
As an aside, I've updated my graphics driver from 178.xx to 180.xx last
Friday, but noticed no difference in this behavior.
It would be worth looking at exactly when the problem occurs - is it
on the stopThreading, the addView, or the startThreading or
thereafter?
The deadlock definitely happens after the view has been added (after
stopThreading, addView, startThreading). It looks to me that it happens on
the first frame after adding the view.
I'd really like to get to the bottom of this. When did you say you were
going to be building your new machine? In the mean time, any chance you can
find some time in your schedule to track down some other machine that would
reproduce this? (JP's and Don's posts seem to indicate it can be reproduced
on Linux on some machines...)
Thanks in advance,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commericial and non commericial
applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include osgDB/ReadFile
#include osgUtil/Optimizer
#include osg/CoordinateSystemNode
#include osg/Switch
#include osgText/Text
#include osgViewer/CompositeViewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include iostream
// Forward declaration
void addView(osgViewer::CompositeViewer* viewer, osg::Node* sceneRoot);
class AddViewHandler : public osgGA::GUIEventHandler
{
public:
AddViewHandler(osgViewer::CompositeViewer* viewer, osg::Node* sceneRoot)
: _viewer(viewer), _sceneRoot(sceneRoot) {}
bool handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter
aa)
{
if (ea.getEventType() == osgGA::GUIEventAdapter::KEYDOWN
ea.getKey()== 'a')
{
addView(_viewer.get(), _sceneRoot);
return true;
}
return false;
}
protected:
osg::observer_ptrosgViewer::CompositeViewer _viewer;
osg::ref_ptrosg::Node _sceneRoot;
};
void addEventHandlers(osgViewer::View* view, osgViewer::CompositeViewer*
viewer, osg::Node* sceneRoot)
{
// set up the camera manipulators.
view-setCameraManipulator( new
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, I forgot to mention that this is running with OSG as compiled yesterday afternoon after an svn update. It's interesting that opening up the windows at the start allows things to run, this suggest that it's allocation of new OpenGL that is problem - which is something that the resize of the GL buffers would have done the trick. I really think there's something fishy with makeCurrent. Perhaps somewhere it's done on the wrong thread the first time, or something like that... It seems one of the graphics threads is stuck trying to make its context current but can't for some reason - it seems to be spinning on a critical section in the graphics driver. Not sure if that makes sense, and in any case it won't help much until you can see the problem firsthand, but that's what it looks like to me. W.r.t opening 40 windows and the app crashing - this is almost certainly down to exhustion of OpenGL resouces. Yeah, I think so too. I could get to 32. I don't think we could get much higher, and I'm not inclined to debug it either, as I doubt our users will open as many - normally in a modeling app you have the classic 4 views (3 ortho + 1 perspective) and maybe a few more when needed, but I would think we'd rarely need more than 10 at a time. Whether the new system will work properly right away and if to does will it reproduce the hang I don't know untill I get to testing, but test it I will. OK, I'm anxiously awaiting any new info. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi JS,
On Thu, Nov 20, 2008 at 7:12 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
As we don't know whether this is the cause of the problem yet, I've
modified J-S's osgviewer.cpp to do the resize. Could users who've
seen problems try this version out, if this works then we have
workaround that end users can apply to existing apps, and we can
figure out a solution to fix it permanently in svn/trunk.
Well, seems like that didn't change anything.
Darn I was hoping that fix would the end of this. The lack of
resize does look to be a bug to me, just not the one causing the
hang/crash in your case...
But following your hint I
checked where the renderingTraversals was stuck:
// wait till the dynamic draw is complete.
if (_endDynamicDrawBlock.valid())
{
// osg::Timer_t startTick = osg::Timer::instance()-tick();
_endDynamicDrawBlock-block();
// osg::notify(osg::NOTICE)Time waiting
osg::Timer::instance()-delta_m(startTick,
osg::Timer::instance()-tick())std::endl;;
}
It's hung on the _endDynamicDrawBlock-block(); line.
When it hung, I had just created a 4th view (=4th context).
Uncoincidentally, there are 4 threads on GraphicsThread::run(), which calls
GraphicsContext::makeCurrent(), which calls
GraphicsWindowWin32::makeCurrentImplementation, which is stuck on the
wglMakeCurrent() call. One of those 4 is stuck in the middle of the graphics
driver DLL, but I'm not sure that's relevant.
I'm not sure how I can see if one of the graphics threads is crashed, as you
indicated... They all seem to be running, just blocked.
Other than those 5 threads (main thread with renderingTraversals() + 4 draw
threads, one per context) there are 7 other threads in the process. I can't
see specifically what they're doing since they're all in graphics driver
code (more or less deeply).
(this all coincides with the stack traces I sent before, but I just thought
explaining it in words would help me understand eventually, and perhaps
others too)
The fact that threads are sitting on a block or bariier is nothing to
worry about unless, it's more that fact that threads that haven't yet
joined it are the problem.
It would be worth looking at exactly when the problem occurs - is it
on the stopThreading, the addView, or the startThreading or
thereafter?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi JS, Robert, what driver version are you using? Any chance OpenGL version string: 2.1.1 NVIDIA 100.14.19 Intel Quad core, Kubuntu 7.10. On Thu, Nov 20, 2008 at 2:40 AM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Also, any chance this has a connection with the buffered_value thread? Seems Robert mentioned that there was some array that was initialized to be of the same size as the number of graphics contexts at startup, and was resized in a non-threadsafe manner if graphics contexts were added at runtime, which is what's happening here... The OSG's buffer_arrays that manage the OpenGL contexts might not be being resized correctly, and this is something to look into. I think it's a long shot though, as corrupted buffer_arrays would lead to OpenGL crashes/problems rather than hangs - unless one context crashes and the rest hang waiting for that thread to join a barrier. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi all, Thanks for testing again. I've had a few other reports for Linux and Windows, some can repro others can't, so I'm trying to get hardware details and driver versions to see if it could be dependent of these factors. Thanks for providing them. Robert suggested off-list that I post these stack traces, so here they are. The first one in particular (jeckle) seems to show the same problem I have been investigating. Thanks to Don Leich for testing on a few different machines (hardware, driver versions). I hope this info will be useful. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ jeckle Linux 2.6.5-7.97-smp x86_64 GNU/Linux OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro FX 1100/AGP/SSE2 OpenGL version string: 1.5.2 NVIDIA 66.29 Added a view with 'a' and followed it each time with 'm' to change the threading model. The test hangs after 4th addView on the 'm' to change back to SingleThreaded. Traces cut-and-pasted from totalview... 1.1 (182952639424) T in pthread_cond_wait 1.10 (1092614496) T in pthread_cond_wait 1.11 (1094711648) T in pthread_cond_wait 1.12 (1096808800) T in pthread_cond_wait 1.13 (1098905952) T in pthread_cond_wait 1.14 (1101003104) T in pthread_cond_wait 1.15 (1103100256) T in pthread_cond_wait pthread_cond_wait, FP=7fbfffd5a0 pthread_cond_wait, FP=7fbfffd5b0 OpenThreads::Condition::wait, FP=7fbfffd610 OpenThreads::BlockCount::block, FP=7fbfffd660 osgViewer::ViewerBase::renderingTraversals, FP=7fbfffd870 osgViewer::ViewerBase::frame, FP=7fbfffd8a0 osgViewer::ViewerBase::run,FP=7fbfffd8d0 osgViewer::CompositeViewer::run, FP=7fbfffd920 main, FP=7fbfffdc60 __libc_start_main, FP=7fbfffdd30 _start,FP=7fbfffdd40 pthread_cond_wait, FP=411ff5b0 pthread_cond_wait, FP=411ff5c0 OpenThreads::Barrier::block, FP=411ff610 osg::BarrierOperation::operator (), FP=411ff630 osg::OperationThread::run, FP=411ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=411ff7b0 start_thread,FP=411ff870 pthread_cond_wait, FP=413ff5b0 pthread_cond_wait, FP=413ff5c0 OpenThreads::Barrier::block, FP=413ff610 osg::BarrierOperation::operator (), FP=413ff630 osg::OperationThread::run, FP=413ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=413ff7b0 start_thread,FP=413ff870 pthread_cond_wait, FP=415ff5b0 pthread_cond_wait, FP=415ff5c0 OpenThreads::Barrier::block, FP=415ff610 osg::BarrierOperation::operator (), FP=415ff630 osg::OperationThread::run, FP=415ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=415ff7b0 start_thread,FP=415ff870 pthread_cond_wait, FP=417ff580 pthread_cond_wait, FP=417ff590 OpenThreads::Barrier::block, FP=417ff5e0 osg::BarrierOperation::operator (), FP=417ff600 osg::OperationThread::run, FP=417ff6b0 osg::GraphicsThread::run,FP=417ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=417ff7b0 start_thread,FP=417ff870 pthread_cond_wait, FP=419ff1c0 pthread_cond_wait, FP=419ff1d0 OpenThreads::Condition::wait,FP=419ff230 OpenThreads::Block::block, FP=419ff280 ...wer::Renderer::TheadSafeQueue::takeFront, FP=419ff2e0 osgViewer::Renderer::draw, FP=419ff460 osgViewer::Renderer::operator (), FP=419ff480 osg::GraphicsContext::runOperations, FP=419ff5a0 osg::RunOperations::operator (), FP=419ff5c0 osg::GraphicsOperation::operator (), FP=419ff600 osg::OperationThread::run, FP=419ff6b0 osg::GraphicsThread::run,FP=419ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=419ff7b0 start_thread,FP=419ff870 pthread_cond_wait, FP=41bff1c0 pthread_cond_wait, FP=41bff1d0 OpenThreads::Condition::wait,FP=41bff230 OpenThreads::Block::block, FP=41bff280 ...wer::Renderer::TheadSafeQueue::takeFront, FP=41bff2e0 osgViewer::Renderer::draw, FP=41bff460 osgViewer::Renderer::operator (), FP=41bff480 osg::GraphicsContext::runOperations, FP=41bff5a0 osg::RunOperations::operator (), FP=41bff5c0 osg::GraphicsOperation::operator (), FP=41bff600 osg::OperationThread::run, FP=41bff6b0 osg::GraphicsThread::run,FP=41bff6e0 ...reads::ThreadPrivateActions::StartThread, FP=41bff7b0 start_thread,FP=41bff870 cartman Linux 2.6.9-5.ELsmp i686 i386 GNU/Linux OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro FX 3450/4000 SDI/PCI/SSE2 OpenGL version string: 2.0.0 NVIDIA 76.76 Alternating 'a' and 'm' we hang after maybe a dozen views are added.
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, OpenGL version string: 2.1.1 NVIDIA 100.14.19 Intel Quad core, Kubuntu 7.10. Hmmm, seems older than what JP and Csaba reported? Or am I reading the numbers wrong? The OSG's buffer_arrays that manage the OpenGL contexts might not be being resized correctly, and this is something to look into. I think it's a long shot though, as corrupted buffer_arrays would lead to OpenGL crashes/problems rather than hangs - unless one context crashes and the rest hang waiting for that thread to join a barrier. Is this join a barrier done during makeCurrent? It's really a shame that you can't repro this issue... It would be so much simpler, I'm just not that familiar with this stuff... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Thu, Nov 20, 2008 at 2:34 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: sparky Linux 2.4.21-102-smp x86_64 GNU/Linux My crash seems to be of this type, although no problem with threading model switching. I wonder if I can try to use software rendering to see if it makes a difference. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi, Jean-Sébastien Guay wrote: Hi Robert, OpenGL version string: 2.1.1 NVIDIA 100.14.19 Intel Quad core, Kubuntu 7.10. Hmmm, seems older than what JP and Csaba reported? Or am I reading the numbers wrong? Yes, it's older. Website says 100.14.19 = Sept 2007. Think I'll have to downgrade kernel to a version that would be happy with older NVidia driver. Robert what kernel version are you using? How do you install NVidia driver? jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi J.P. et al., On Thu, Nov 20, 2008 at 3:01 PM, J.P. Delport [EMAIL PROTECTED] wrote: Yes, it's older. Website says 100.14.19 = Sept 2007. Think I'll have to downgrade kernel to a version that would be happy with older NVidia driver. Robert what kernel version are you using? 2.6.22-15-generic How do you install NVidia driver? I've let Kubuntu just install what it maintains in the repository for 7.10. Next week I'll be building a new machine, based on Core i7 + X58, I'll probably install Kubuntu 8.10 on it and see how I get on with KDE 4.1.x as a main dev machine. I might revert back to 8.04 though if KDE 4.1.x can't yet cope with multiple graphics cards/multi-headed. Either way I'll another multi-threaded system to test this issue against. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Thu, Nov 20, 2008 at 3:51 PM, Csaba Halász [EMAIL PROTECTED] wrote: I wonder if I can try to use software rendering to see if it makes a difference. I have run it with mesa in a nested x server, no hangs. After each added view, however, I got a single Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) message (ie. *not* every frame). Don't know if that is relevant. Also, the software rendering might be too slow to produce the problem. Anybody got some further suggestions? -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Csaba et. al, On Thu, Nov 20, 2008 at 3:50 PM, Csaba Halász [EMAIL PROTECTED] wrote: I have run it with mesa in a nested x server, no hangs. After each added view, however, I got a single Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) message (ie. *not* every frame). Don't know if that is relevant. Also, the software rendering might be too slow to produce the problem. Anybody got some further suggestions? One thought I have about the a possible failure mode is that perhaps one graphics context thread is hanging or crashing, and the rest of the threads succeed rendering their frame and get all the way to the barrier at the end of the frame. This would result is stack traces where all but one would be hanging on a barrier. if this is correct then the issue is about finding out why one of the graphics threads fails. It could be an OpenGL object management issue, and the invalid operations might be an early warning of this. The fact that problems exists across many machines with quite different OS/hardware/drivers strongly suggests an OSG bug, and that the rest of the variables are just co-incidence. I think the best lead would be that perhaps the texture object/display lists buffer_value containers aren't being resized to fit the new number of contexts which the app is running single threaded. In theory addView should be stopping all threads, and then issuing the Node::resizeGLObejcts() on the scene graph so handling this situation, but perhaps this isn't happening. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi All,
On Thu, Nov 20, 2008 at 4:01 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
I think the best lead would be that perhaps the texture object/display
lists buffer_value containers aren't being resized to fit the new
number of contexts which the app is running single threaded. In
theory addView should be stopping all threads, and then issuing the
Node::resizeGLObejcts() on the scene graph so handling this situation,
but perhaps this isn't happening.
I've looked into the
CompositeViewer:::addView()/View::setSceneData()/Viewer::setSceneData()
methods and only the Viewer::setSceneData() has a call to resize the
GL objects. The actual code looks like:
void Viewer::setSceneData(osg::Node* node)
{
setReferenceTime(0.0);
View::setSceneData(node);
if (_threadingModel!=SingleThreaded getSceneData())
{
// make sure that existing scene graph objects are allocated
with thread safe ref/unref
getSceneData()-setThreadSafeRefUnref(true);
// update the scene graph so that it has enough GL object
buffer memory for the graphics contexts that will be using it.
getSceneData()-resizeGLObjectBuffers(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsContexts());
}
}
My guess is that we need to move the resize/setThreadSafeRefUnref() up
into the View::setSceneData() method. The Viewer::setSceneData()
method is a viewer so has access to members of ViewerBase that View
doesn't have. Another issue is that if we are setting the View up
prior to any call to stopThreading as the resize isn't thread safe.
As we don't know whether this is the cause of the problem yet, I've
modified J-S's osgviewer.cpp to do the resize. Could users who've
seen problems try this version out, if this works then we have
workaround that end users can apply to existing apps, and we can
figure out a solution to fix it permanently in svn/trunk.
Robert.
Robert.
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commericial and non commericial applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include osgDB/ReadFile
#include osgUtil/Optimizer
#include osg/CoordinateSystemNode
#include osg/Switch
#include osgText/Text
#include osgViewer/CompositeViewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include iostream
void addEventHandlers(osgViewer::View* view)
{
// set up the camera manipulators.
view-setCameraManipulator( new osgGA::TrackballManipulator() );
// add the state manipulator
view-addEventHandler( new osgGA::StateSetManipulator(view-getCamera()-getOrCreateStateSet()) );
// add the thread model handler
view-addEventHandler(new osgViewer::ThreadingHandler);
// add the window size toggle handler
view-addEventHandler(new osgViewer::WindowSizeHandler);
// add the stats handler
view-addEventHandler(new osgViewer::StatsHandler);
// add the record camera path handler
view-addEventHandler(new osgViewer::RecordCameraPathHandler);
// add the LOD Scale handler
view-addEventHandler(new osgViewer::LODScaleHandler);
// add the screen capture handler
view-addEventHandler(new osgViewer::ScreenCaptureHandler);
}
class AddViewHandler : public osgGA::GUIEventHandler
{
public:
AddViewHandler(osgViewer::CompositeViewer* viewer, osg::Node* sceneRoot)
: _viewer(viewer), _sceneRoot(sceneRoot) {}
bool handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter aa)
{
if (ea.getEventType() == osgGA::GUIEventAdapter::KEYDOWN ea.getKey()== 'a')
{
osgViewer::View* view = new osgViewer::View;
view-setUpViewInWindow(50, 50, 800, 600);
view-getCamera()-getGraphicsContext()-realize();
view-setSceneData(_sceneRoot.get());
addEventHandlers(view);
_viewer-stopThreading();
_viewer-addView(view);
osg::notify(osg::NOTICE)osg::DisplaySettings::instance()-getMaxNumberOfGraphicsContexts()= osg::DisplaySettings::instance()-getMaxNumberOfGraphicsContexts()std::endl;
view-getSceneData()-setThreadSafeRefUnref(true);
view-getSceneData()-resizeGLObjectBuffers(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsContexts());
_viewer-startThreading();
return true;
}
return false;
}
protected:
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi J-S, J.P., and non-initialed persons of interest (or P.O.I.s), J-S beat me and posted the traces I mailed to him off-line yesterday. I was doing another round of tests to see if I could really duplicate his exact problem. I can't. I don't get the hang unless I change the threading model. On all tested systems I could create 40 or more addView windows when staying with SingleThreaded. A few notes on an anomoly or two in my results. System cartman shows many more threads than expected. Perhaps there's a bug in gdb that shows the same thread multiple time. Where I mentioned missing cows, I would get a background colored window and no other graphics. System curly has a package for a driver fire-glfglrx_4_3_0-8.10.19-1.i386.rpm, but since it's very obviously draw limited it probably really is rendering with Mesa. Another system that is known to be Mesa didn't have any problems with the addView test. System sparky may have an entirely different problem. We're cross platform CAE developers here and upgrade our drivers very infrequently. I suspect that is why we may be finding so many problems with OSG and threading. -Don Hi all, Thanks for testing again. I've had a few other reports for Linux and Windows, some can repro others can't, so I'm trying to get hardware details and driver versions to see if it could be dependent of these factors. Thanks for providing them. Robert suggested off-list that I post these stack traces, so here they are. The first one in particular (jeckle) seems to show the same problem I have been investigating. Thanks to Don Leich for testing on a few different machines (hardware, driver versions). I hope this info will be useful. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Interesting. My system sparky has OpenGL version string: 2.1.1 NVIDIA 100.14.19 AMD-64, SuSe 9.2 (I think) rather old kernel 2.4.21-102-smp -Don Robert, what driver version are you using? Any chance OpenGL version string: 2.1.1 NVIDIA 100.14.19 Intel Quad core, Kubuntu 7.10. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert,
As we don't know whether this is the cause of the problem yet, I've
modified J-S's osgviewer.cpp to do the resize. Could users who've
seen problems try this version out, if this works then we have
workaround that end users can apply to existing apps, and we can
figure out a solution to fix it permanently in svn/trunk.
I'm in the process of building OSG and the modified osgviewer.cpp
following an svn update which I shouldn't have done (would have been
quicker). I'll let you know my results.
I've seen another threading-related problem. When creating a new
context, I'm getting crashes caused by the fact that
GraphicsWindowWin32::realize() calls makeCurrent(), which looks like this:
bool GraphicsContext::makeCurrent()
{
bool result = makeCurrentImplementation();
if (result)
{
_threadOfLastMakeCurrent = OpenThreads::Thread::CurrentThread();
// initialize extension process, not only initializes on first
// call, will be a non-op on subsequent calls.
getState()-initializeExtensionProcs();
}
return result;
}
The call to getState()-initializeExtensionProcs() calls glGetString(
GL_VERSION ) to check some things. Now, it can happen that between the
makeCurrentImplementation() and the glGetString() in
initializeExtensionProcs(), some other graphics thread that wanted to
draw called makeCurrent() as well, and thus when glGetVersion() is
called it no longer has the context current.
Obviously we have to be pretty unlucky to run into this, but as the
number of contexts becomes larger, it has more chances of happening (or
even the opposite, a graphics thread doing some drawing and then we
construct a new GraphicsWindowWin32 which calls makeCurrent() and the
graphics thread's context is no longer current).
Whichever thread we create contexts on, I think there's no way to be
sure that no graphics thread is currently drawing (since the draw for
thread n-1 might overlap the event,update,cull of frame n in certain
threading modes) am I right? Should there be some mutex to prevent
makeCurrent() while another thread is drawing, or makeCurrent() while a
context is being created?
I'm trying to get my head around these threading problems. Keeping track
of on which thread a given method will be called is a bit hard sometimes.
Thanks,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert,
As we don't know whether this is the cause of the problem yet, I've
modified J-S's osgviewer.cpp to do the resize. Could users who've
seen problems try this version out, if this works then we have
workaround that end users can apply to existing apps, and we can
figure out a solution to fix it permanently in svn/trunk.
Well, seems like that didn't change anything. But following your hint I
checked where the renderingTraversals was stuck:
// wait till the dynamic draw is complete.
if (_endDynamicDrawBlock.valid())
{
// osg::Timer_t startTick = osg::Timer::instance()-tick();
_endDynamicDrawBlock-block();
// osg::notify(osg::NOTICE)Time waiting
osg::Timer::instance()-delta_m(startTick,
osg::Timer::instance()-tick())std::endl;;
}
It's hung on the _endDynamicDrawBlock-block(); line.
When it hung, I had just created a 4th view (=4th context).
Uncoincidentally, there are 4 threads on GraphicsThread::run(), which
calls GraphicsContext::makeCurrent(), which calls
GraphicsWindowWin32::makeCurrentImplementation, which is stuck on the
wglMakeCurrent() call. One of those 4 is stuck in the middle of the
graphics driver DLL, but I'm not sure that's relevant.
I'm not sure how I can see if one of the graphics threads is crashed, as
you indicated... They all seem to be running, just blocked.
Other than those 5 threads (main thread with renderingTraversals() + 4
draw threads, one per context) there are 7 other threads in the process.
I can't see specifically what they're doing since they're all in
graphics driver code (more or less deeply).
(this all coincides with the stack traces I sent before, but I just
thought explaining it in words would help me understand eventually, and
perhaps others too)
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Thu, Nov 20, 2008 at 8:12 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: When it hung, I had just created a 4th view (=4th context). Uncoincidentally, there are 4 threads on GraphicsThread::run(), which calls GraphicsContext::makeCurrent(), which calls GraphicsWindowWin32::makeCurrentImplementation, which is stuck on the wglMakeCurrent() call. One of those 4 is stuck in the middle of the graphics driver DLL, but I'm not sure that's relevant. Yes, exactly the same for me. And I am on linux. I wondered if simply calling cancel() on the threads is a good idea. I'd feel a lot better if the threads would check for an exit flag at a well-defined place. Could it be possible that one of the threads is inside the gl lib doing something and then it gets abruptly cancelled without releasing some critical resource? Of course the gl lib should make sure cancellation is disabled while inside such code, but who knows. Assuming a resource is left locked could explain why the makeCurrent is blocked - it might be (busy-)waiting on that very resource. Also, I have added a join() call after the cancel in GraphicsContext.cpp and Camera.cpp, that have the strange effect of completely locking up X and not just the test app. Robert's changed version doesn't seem to make a difference here. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Thu, Nov 20, 2008 at 4:50 PM, Csaba Halász [EMAIL PROTECTED] wrote: On Thu, Nov 20, 2008 at 3:51 PM, Csaba Halász [EMAIL PROTECTED] wrote: I wonder if I can try to use software rendering to see if it makes a difference. I have run it with mesa in a nested x server, no hangs. After each added view, however, I got a single Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) message (ie. *not* every frame). Don't know if that is relevant. Also, the software rendering might be too slow to produce the problem. Anybody got some further suggestions? I think the intel driver is entirely open-source, can somebody try with that? That should at least point to where the rogue thread is spinning. Assuming it exhibits the same behaviour. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi J-S, I've just upgraded OSG on two Linux machines to latest svn and I can still reproduce the hang with your example. I need to add around 8-12 new windows. The one machine is a dual-core laptop with GeForce Go 7400. The other is a quad-core desktop with a GTX280. Both are running Debian Sid 32-bit. NVidia driver version 177.82. OSG svn 9181. Tried debug and release version on the laptop, both hang. Not sure why Robert can't reproduce the problem. rgds jp Jean-Sébastien Guay wrote: Hi Robert, Thanks a lot for testing. I could reproduce any crashes on press 'a' but on pressing escape the code crashed due to a circular reference that your AddViewHandler introduces with its local ref_ptrCompositeViewer. Changing this to observer_ptr fixes the crash on exit. Yes of course, I didn't really focus on that as the deadlock is a bigger issue and this is just a quick tester. I've removed them I still can't reproduce the crash so it does seem to be working OK. Weird, I can still get the deadlock, and JP seems to get it too on Linux. I wonder what's different. What threading mode were you running? One thing to note is that I've merged a threading fix to CompositeViewer's since 2.6. Perhaps this is having an effect, try svn/trunk. I am - this example was compiled with SVN as of this Monday. Still getting a deadlock after a variable number of added views. Any other ideas as to what I could be doing wrong? Thanks again, J-S -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi JP, Thanks for testing again. I've had a few other reports for Linux and Windows, some can repro others can't, so I'm trying to get hardware details and driver versions to see if it could be dependent of these factors. Thanks for providing them. Not sure why Robert can't reproduce the problem. Yeah, weird. He didn't mention his driver version (hint, hint) ;-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
I tried J-S's test on a couple of systems in my office and got it to hang on several. I'm using OSG 2.6.0 and our drivers are far from bleeding edge (some are several years old). I think I have coaxed additional nastyness from the test by typing an 'm' to change the threading model after each 'a'. This trace is typical of the set, although not identical. I can make serveral more traces available off-line. This system is Linux kernal 2.6.5-7.97-smp x86_64 GNU/Linux; Quadro FX 1100/AGP/SSE2 1.5.2 NVIDIA 66.29. The test hangs after 4th addView on the 'm' to change back to SingleThreaded. 1.1 (182952639424) T in pthread_cond_wait 1.10 (1092614496) T in pthread_cond_wait 1.11 (1094711648) T in pthread_cond_wait 1.12 (1096808800) T in pthread_cond_wait 1.13 (1098905952) T in pthread_cond_wait 1.14 (1101003104) T in pthread_cond_wait 1.15 (1103100256) T in pthread_cond_wait pthread_cond_wait, FP=7fbfffd5a0 pthread_cond_wait, FP=7fbfffd5b0 OpenThreads::Condition::wait, FP=7fbfffd610 OpenThreads::BlockCount::block, FP=7fbfffd660 osgViewer::ViewerBase::renderingTraversals, FP=7fbfffd870 osgViewer::ViewerBase::frame, FP=7fbfffd8a0 osgViewer::ViewerBase::run,FP=7fbfffd8d0 osgViewer::CompositeViewer::run, FP=7fbfffd920 main, FP=7fbfffdc60 __libc_start_main, FP=7fbfffdd30 _start,FP=7fbfffdd40 pthread_cond_wait, FP=411ff5b0 pthread_cond_wait, FP=411ff5c0 OpenThreads::Barrier::block, FP=411ff610 osg::BarrierOperation::operator (), FP=411ff630 osg::OperationThread::run, FP=411ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=411ff7b0 start_thread,FP=411ff870 pthread_cond_wait, FP=413ff5b0 pthread_cond_wait, FP=413ff5c0 OpenThreads::Barrier::block, FP=413ff610 osg::BarrierOperation::operator (), FP=413ff630 osg::OperationThread::run, FP=413ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=413ff7b0 start_thread,FP=413ff870 pthread_cond_wait, FP=415ff5b0 pthread_cond_wait, FP=415ff5c0 OpenThreads::Barrier::block, FP=415ff610 osg::BarrierOperation::operator (), FP=415ff630 osg::OperationThread::run, FP=415ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=415ff7b0 start_thread,FP=415ff870 pthread_cond_wait, FP=417ff580 pthread_cond_wait, FP=417ff590 OpenThreads::Barrier::block, FP=417ff5e0 osg::BarrierOperation::operator (), FP=417ff600 osg::OperationThread::run, FP=417ff6b0 osg::GraphicsThread::run,FP=417ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=417ff7b0 start_thread,FP=417ff870 pthread_cond_wait, FP=419ff1c0 pthread_cond_wait, FP=419ff1d0 OpenThreads::Condition::wait,FP=419ff230 OpenThreads::Block::block, FP=419ff280 ...wer::Renderer::TheadSafeQueue::takeFront, FP=419ff2e0 osgViewer::Renderer::draw, FP=419ff460 osgViewer::Renderer::operator (), FP=419ff480 osg::GraphicsContext::runOperations, FP=419ff5a0 osg::RunOperations::operator (), FP=419ff5c0 osg::GraphicsOperation::operator (), FP=419ff600 osg::OperationThread::run, FP=419ff6b0 osg::GraphicsThread::run,FP=419ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=419ff7b0 start_thread,FP=419ff870 pthread_cond_wait, FP=41bff1c0 pthread_cond_wait, FP=41bff1d0 OpenThreads::Condition::wait,FP=41bff230 OpenThreads::Block::block, FP=41bff280 ...wer::Renderer::TheadSafeQueue::takeFront, FP=41bff2e0 osgViewer::Renderer::draw, FP=41bff460 osgViewer::Renderer::operator (), FP=41bff480 osg::GraphicsContext::runOperations, FP=41bff5a0 osg::RunOperations::operator (), FP=41bff5c0 osg::GraphicsOperation::operator (), FP=41bff600 osg::OperationThread::run, FP=41bff6b0 osg::GraphicsThread::run,FP=41bff6e0 ...reads::ThreadPrivateActions::StartThread, FP=41bff7b0 start_thread,FP=41bff870 -Don =0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0= Donald Leich Mailto:[EMAIL PROTECTED] Senior Software Developer Voice: 201-460-4700 ext: 215 Intelligent Light FAX: 201-460-0221 301 Route 17 North, 7th Floor Rutherford, NJ 07070-2575 Visit our web site at http://www.ilight.com =0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0= Hi J-S, I've just upgraded OSG on two Linux machines to latest svn and I can still reproduce the hang with your example. I need to add around 8-12 new windows. The one machine is a dual-core laptop with GeForce Go 7400. The other is a quad-core desktop with a GTX280. Both are running Debian Sid 32-bit. NVidia driver version 177.82. OSG svn 9181. Tried debug and release version on the
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Wed, Nov 19, 2008 at 10:42 PM, Don Leich [EMAIL PROTECTED] wrote: pthread_cond_wait, FP=7fbfffd5a0 pthread_cond_wait, FP=7fbfffd5b0 OpenThreads::Condition::wait, FP=7fbfffd610 OpenThreads::BlockCount::block, FP=7fbfffd660 osgViewer::ViewerBase::renderingTraversals, FP=7fbfffd870 osgViewer::ViewerBase::frame, FP=7fbfffd8a0 osgViewer::ViewerBase::run,FP=7fbfffd8d0 osgViewer::CompositeViewer::run, FP=7fbfffd920 main, FP=7fbfffdc60 __libc_start_main, FP=7fbfffdd30 _start,FP=7fbfffdd40 I had a recent submission affecting this part of the code. I have locally reverted that and I still see the hang so it is not likely to be the cause. Nevertheless, you could try for yourselves. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi people, my call stacks show that all the waiting is going on because one of the threads is stuck in makeCurrent: #0 0x7f34b8b7a727 in sched_yield () from /lib/libc.so.6 #1 0x7f34b8385665 in ?? () from /usr/lib/libGLcore.so.1 #2 0x7f34b80a0d8a in ?? () from /usr/lib/libGLcore.so.1 #3 0x7f34b994f056 in ?? () from /usr/lib/libGL.so.1 #4 0x7f34b995386b in ?? () from /usr/lib/libGL.so.1 #5 0x7f34bb641843 in osgViewer::GraphicsWindowX11::makeCurrentImplementation (this=0x11930d0) at /home/hcs/src/OpenSceneGraph/src/osgViewer/GraphicsWindowX11.cpp:804 #6 0x7f34ba21013c in osg::GraphicsContext::makeCurrent (this=0x11930d0) at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsContext.cpp:512 #7 0x7f34ba21b4b6 in osg::GraphicsThread::run (this=0x7f34b01e7ef0) at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsThread.cpp:33 #8 0x7f34b9cd0f9c in OpenThreads::ThreadPrivateActions::StartThread (data=0x7f34b01e7f08) at /home/hcs/src/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:172 #9 0x7f34b9ab73f7 in start_thread () from /lib/libpthread.so.0 #10 0x7f34b8b9397d in clone () from /lib/libc.so.6 #11 0x in ?? () And it isn't a proper deadlock, more like a busy wait (single thread is running at 100% cpu) For the record, I am on linux, nvidia driver 177.80. I wonder if any ATI users are seeing this? -- Hope this helps, Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Csaba, my call stacks show that all the waiting is going on because one of the threads is stuck in makeCurrent: And it isn't a proper deadlock, more like a busy wait (single thread is running at 100% cpu) For the record, I am on linux, nvidia driver 177.80. Yep, seems like that's the same thing I'm seeing on Windows, and JP and Don are seeing on Linux. Robert, what driver version are you using? Any chance you could try the same version Csaba or JP use, then you might be able to reproduce the issue. Also, any chance this has a connection with the buffered_value thread? Seems Robert mentioned that there was some array that was initialized to be of the same size as the number of graphics contexts at startup, and was resized in a non-threadsafe manner if graphics contexts were added at runtime, which is what's happening here... Thanks again for testing everyone, I'm really hoping we get to the bottom of this one. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi all,
No answers yet, so either I was too verbose and scared off people or no
one has anything to say...
I should mention, I would be interested if someone would try the example
I attached to the last mail even on other platforms than Windows (Linux
mostly) to see if I'm doing anything wrong in a more general sense.
Thanks in advance,
J-S
Jean-Sébastien Guay wrote:
Hi all,
We're currently creating a new app where we need to be able to create
new views, each of which needs to have a separate graphics context
(because they need to be attached to Qt windows - so each needs to get a
unique window handle).
When adding views, I'm hitting what seems to be a threading issue
(deadlock or something like that). It'll happen after adding 2, 3 or 4
views, not always the same number, but I can rarely get more than 5
total. On the call stack, I can see one thread per context is in
GraphicsWindowWin32::makeCurrentImpl() (this is DrawThreadPerContext, so
that's ok), and a third one is in ViewerBase::renderingTraversals() on a
conditionalWait, and they all seem to be stalled there. I'll copy the
stack traces below.
I've reproduced the problem even without Qt, by modifying osgviewer.cpp,
adding an event handler that just creates a new view, calls
setUpViewInWindow() and sets the scene root on it to the same as the
first view. I've tried surrounding the addView call with stopThreading()
and startThreading(), but it doesn't seem to change anything.
I've attached my modified osgviewer.cpp. If someone's inclined to try it
out, just start it with cow.osg for example, and press 'a' to add a view
(note that the 'a' key will only work on the first window).
Is there anything else I need to be careful of when adding views at run
time? Anything I need to do to make this work?
Thanks in advance,
J-S
Stack traces:
Thread 1
=
[EMAIL PROTECTED]()
[EMAIL PROTECTED]() + 0xc bytes
[EMAIL PROTECTED]() + 0x84 bytes
[EMAIL PROTECTED]() + 0x12 bytes
ot11-OpenThreadsd.dll!OpenThreads::cooperativeWait(void *
waitHandle=0x0318, unsigned long timeout=4294967295) Line 55 + 0x10
bytesC++
ot11-OpenThreadsd.dll!OpenThreads::Win32ConditionPrivateData::wait(OpenThreads::Mutex
external_mutex={...}, long timeout_ms=-1) Line 109 + 0x1d bytesC++
ot11-OpenThreadsd.dll!OpenThreads::Condition::wait(OpenThreads::Mutex *
mutex=0x0237c1e4) Line 63C++
osg50-osgViewerd.dll!OpenThreads::BlockCount::block() Line 133 +
0x17 bytesC++
osg50-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals()
Line 753C++
osg50-osgViewerd.dll!osgViewer::ViewerBase::frame(double
simulationTime=1.7976931348623157e+308) Line 608 + 0xf bytesC++
osg50-osgViewerd.dll!osgViewer::ViewerBase::run() Line 580 + 0x1b
bytesC++
osg50-osgViewerd.dll!osgViewer::CompositeViewer::run() Line 219
C++
AddView.exe!main(int argc=2, char * * argv=0x0229c828) Line 177 +
0xe bytesC++
AddView.exe!__tmainCRTStartup() Line 597 + 0x19 bytesC
AddView.exe!mainCRTStartup() Line 414C
[EMAIL PROTECTED]@12() + 0x12 bytes
[EMAIL PROTECTED]() + 0x27 bytes
[EMAIL PROTECTED]() + 0x1b bytes
Thread 2
=
[EMAIL PROTECTED]()
[EMAIL PROTECTED]() + 0xc bytes
[EMAIL PROTECTED]() - 0x51 bytes
[EMAIL PROTECTED]() + 0xd7 bytes
[EMAIL PROTECTED]() + 0x1f bytes
nvoglv32.dll!6970f597()
[Frames below may be incorrect and/or missing, no symbols loaded
for nvoglv32.dll]
[EMAIL PROTECTED]@12() + 0x12 bytes
[EMAIL PROTECTED]() + 0x27 bytes
[EMAIL PROTECTED]() + 0x1b bytes
Thread 3
=
[EMAIL PROTECTED]()
[EMAIL PROTECTED]() + 0xc bytes
[EMAIL PROTECTED]() + 0x84 bytes
[EMAIL PROTECTED]() + 0x12 bytes
nvoglv32.dll!69705b31()
[Frames below may be incorrect and/or missing, no symbols loaded
for nvoglv32.dll]
nvoglv32.dll!696215b0()
nvoglv32.dll!69621f14()
nvoglv32.dll!697057a9()
[EMAIL PROTECTED]@12() + 0x12 bytes
[EMAIL PROTECTED]() + 0x27 bytes
[EMAIL PROTECTED]() + 0x1b bytes
Thread 4
=
nvoglv32.dll!69621881()
[Frames below may be incorrect and/or missing, no symbols loaded
for nvoglv32.dll]
nvoglv32.dll!69714ba0()
nvoglv32.dll!6970416c()
[EMAIL PROTECTED]() + 0x3b bytes
[EMAIL PROTECTED]() + 0xd5 bytes
[EMAIL PROTECTED]() + 0x8e bytes
osg50-osgViewerd.dll!osgViewer::GraphicsWindowWin32::makeCurrentImplementation()
Line 1701 + 0x1c bytesC++
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi, ran it under Linux Nvidia 177.82. First time freeze on adding 3rd extra view 2nd time freeze on adding 5th 3rd time freeze on adding 7th 4th time freeze on adding 4th backtrace on last: thread 0: #0 0xb8022424 in __kernel_vsyscall () #1 0xb7732025 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb782f75d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libc.so.6 #3 0xb79cbb08 in OpenThreads::Condition::wait () from /usr/local/lib/libOpenThreads.so.11 #4 0xb7d9fb81 in osgViewer::ViewerBase::renderingTraversals () from /usr/local/lib/libosgViewer.so.47 #5 0xb7d9e0e3 in osgViewer::ViewerBase::frame () from /usr/local/lib/libosgViewer.so.47 #6 0xb7d9e20d in osgViewer::ViewerBase::run () from /usr/local/lib/libosgViewer.so.47 #7 0xb7d5492e in osgViewer::CompositeViewer::run () from /usr/local/lib/libosgViewer.so.47 thread 1: #0 0xb8022424 in __kernel_vsyscall () #1 0xb7732025 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb782f75d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libc.so.6 #3 0xb79cbb08 in OpenThreads::Condition::wait () from /usr/local/lib/libOpenThreads.so.11 #4 0xb7d9fb81 in osgViewer::ViewerBase::renderingTraversals () from /usr/local/lib/libosgViewer.so.47 #5 0xb7d9e0e3 in osgViewer::ViewerBase::frame () from /usr/local/lib/libosgViewer.so.47 #6 0xb7d9e20d in osgViewer::ViewerBase::run () from /usr/local/lib/libosgViewer.so.47 #7 0xb7d5492e in osgViewer::CompositeViewer::run () from /usr/local/lib/libosgViewer.so.47 thread 2: #0 0xb8022424 in __kernel_vsyscall () #1 0xb7734c99 in __lll_lock_wait () from /lib/i686/cmov/libpthread.so.0 #2 0xb77300d3 in _L_lock_291 () from /lib/i686/cmov/libpthread.so.0 #3 0xb772fb36 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0 #4 0xb782f926 in pthread_mutex_lock () from /lib/i686/cmov/libc.so.6 #5 0xb7632c91 in ?? () from /usr/lib/libGL.so.1 #6 0xb76a2080 in ?? () from /usr/lib/libGL.so.1 thread 3: #0 0xb8022424 in __kernel_vsyscall () #1 0xb7734c99 in __lll_lock_wait () from /lib/i686/cmov/libpthread.so.0 #2 0xb77300c4 in _L_lock_89 () from /lib/i686/cmov/libpthread.so.0 #3 0xb772f9f2 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0 #4 0xb782f926 in pthread_mutex_lock () from /lib/i686/cmov/libc.so.6 #5 0xb79cbcd3 in OpenThreads::Mutex::lock () from /usr/local/lib/libOpenThreads.so.11 #6 0xb7d659d9 in osgViewer::Renderer::draw () from /usr/local/lib/libosgViewer.so.47 #7 0xb7d63408 in osgViewer::Renderer::operator() () from /usr/local/lib/libosgViewer.so.47 #8 0xb7ee6001 in osg::GraphicsContext::runOperations () from /usr/local/lib/libosg.so.47 #9 0xb7eed53d in osg::RunOperations::operator() () from /usr/local/lib/libosg.so.47 #10 0xb7eed657 in osg::GraphicsOperation::operator() () from /usr/local/lib/libosg.so.47 #11 0xb7f296f9 in osg::OperationThread::run () from /usr/local/lib/libosg.so.47 #12 0xb7eed6e9 in osg::GraphicsThread::run () from /usr/local/lib/libosg.so.47 #13 0xb79cb1cd in OpenThreads::ThreadPrivateActions::StartThread () from /usr/local/lib/libOpenThreads.so.11 #14 0xb772e4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #15 0xb782161e in clone () from /lib/i686/cmov/libc.so.6 thread 4: #0 0xb6dd4156 in ?? () from /usr/lib/libGLcore.so.1 #1 0x08395698 in ?? () #2 0xb7899160 in ?? () from /lib/i686/cmov/libc.so.6 #3 0x98402317 in ?? () #4 0x in ?? () thread 5: #0 0xb8022424 in __kernel_vsyscall () #1 0xb7734c99 in __lll_lock_wait () from /lib/i686/cmov/libpthread.so.0 #2 0xb77300c4 in _L_lock_89 () from /lib/i686/cmov/libpthread.so.0 #3 0xb772f9f2 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0 #4 0xb782f926 in pthread_mutex_lock () from /lib/i686/cmov/libc.so.6 #5 0xb79cbcd3 in OpenThreads::Mutex::lock () from /usr/local/lib/libOpenThreads.so.11 #6 0xb7d659d9 in osgViewer::Renderer::draw () from /usr/local/lib/libosgViewer.so.47 #7 0xb7d63408 in osgViewer::Renderer::operator() () from /usr/local/lib/libosgViewer.so.47 #8 0xb7ee6001 in osg::GraphicsContext::runOperations () from /usr/local/lib/libosg.so.47 #9 0xb7eed53d in osg::RunOperations::operator() () from /usr/local/lib/libosg.so.47 #10 0xb7eed657 in osg::GraphicsOperation::operator() () from /usr/local/lib/libosg.so.47 #11 0xb7f296f9 in osg::OperationThread::run () from /usr/local/lib/libosg.so.47 #12 0xb7eed6e9 in osg::GraphicsThread::run () from /usr/local/lib/libosg.so.47 #13 0xb79cb1cd in OpenThreads::ThreadPrivateActions::StartThread () from /usr/local/lib/libOpenThreads.so.11 #14 0xb772e4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #15 0xb782161e in clone () from /lib/i686/cmov/libc.so.6 thread 6: #0 0xb8022424 in __kernel_vsyscall () #1 0xb7734c99 in __lll_lock_wait () from /lib/i686/cmov/libpthread.so.0 #2 0xb77300d3 in _L_lock_291 () from /lib/i686/cmov/libpthread.so.0 #3
Re: [osg-users] CompositeViewer addView threading issue on Windows?
No answers, but I have seen in my own work that adding a new view to an
existing (and running) CompositeViewer causes a crash when the CompositeViewer
was running in anything other than single-threaded mode when it tries to stop
the thread to add the new view (inside CompositeViewer). I had just assumed I
was doing something wrong...which may still be the case, but it sounds similar
enough to your problem.
- John
-Original Message-
From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2008 9:10 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi all,
No answers yet, so either I was too verbose and scared off people or no
one has anything to say...
I should mention, I would be interested if someone would try the example
I attached to the last mail even on other platforms than Windows (Linux
mostly) to see if I'm doing anything wrong in a more general sense.
Thanks in advance,
J-S
Jean-Sébastien Guay wrote:
Hi all,
We're currently creating a new app where we need to be able to create
new views, each of which needs to have a separate graphics context
(because they need to be attached to Qt windows - so each needs to get a
unique window handle).
When adding views, I'm hitting what seems to be a threading issue
(deadlock or something like that). It'll happen after adding 2, 3 or 4
views, not always the same number, but I can rarely get more than 5
total. On the call stack, I can see one thread per context is in
GraphicsWindowWin32::makeCurrentImpl() (this is DrawThreadPerContext, so
that's ok), and a third one is in ViewerBase::renderingTraversals() on a
conditionalWait, and they all seem to be stalled there. I'll copy the
stack traces below.
I've reproduced the problem even without Qt, by modifying osgviewer.cpp,
adding an event handler that just creates a new view, calls
setUpViewInWindow() and sets the scene root on it to the same as the
first view. I've tried surrounding the addView call with stopThreading()
and startThreading(), but it doesn't seem to change anything.
I've attached my modified osgviewer.cpp. If someone's inclined to try it
out, just start it with cow.osg for example, and press 'a' to add a view
(note that the 'a' key will only work on the first window).
Is there anything else I need to be careful of when adding views at run
time? Anything I need to do to make this work?
Thanks in advance,
J-S
Stack traces:
Thread 1
=
[EMAIL PROTECTED]()
[EMAIL PROTECTED]() + 0xc bytes
[EMAIL PROTECTED]() + 0x84 bytes
[EMAIL PROTECTED]() + 0x12 bytes
ot11-OpenThreadsd.dll!OpenThreads::cooperativeWait(void *
waitHandle=0x0318, unsigned long timeout=4294967295) Line 55 + 0x10
bytesC++
ot11-OpenThreadsd.dll!OpenThreads::Win32ConditionPrivateData::wait(OpenThreads::Mutex
external_mutex={...}, long timeout_ms=-1) Line 109 + 0x1d bytesC++
ot11-OpenThreadsd.dll!OpenThreads::Condition::wait(OpenThreads::Mutex *
mutex=0x0237c1e4) Line 63C++
osg50-osgViewerd.dll!OpenThreads::BlockCount::block() Line 133 +
0x17 bytesC++
osg50-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals()
Line 753C++
osg50-osgViewerd.dll!osgViewer::ViewerBase::frame(double
simulationTime=1.7976931348623157e+308) Line 608 + 0xf bytesC++
osg50-osgViewerd.dll!osgViewer::ViewerBase::run() Line 580 + 0x1b
bytesC++
osg50-osgViewerd.dll!osgViewer::CompositeViewer::run() Line 219
C++
AddView.exe!main(int argc=2, char * * argv=0x0229c828) Line 177 +
0xe bytesC++
AddView.exe!__tmainCRTStartup() Line 597 + 0x19 bytesC
AddView.exe!mainCRTStartup() Line 414C
[EMAIL PROTECTED]@12() + 0x12 bytes
[EMAIL PROTECTED]() + 0x27 bytes
[EMAIL PROTECTED]() + 0x1b bytes
Thread 2
=
[EMAIL PROTECTED]()
[EMAIL PROTECTED]() + 0xc bytes
[EMAIL PROTECTED]() - 0x51 bytes
[EMAIL PROTECTED]() + 0xd7 bytes
[EMAIL PROTECTED]() + 0x1f bytes
nvoglv32.dll!6970f597()
[Frames below may be incorrect and/or missing, no symbols loaded
for nvoglv32.dll]
[EMAIL PROTECTED]@12() + 0x12 bytes
[EMAIL PROTECTED]() + 0x27 bytes
[EMAIL PROTECTED]() + 0x1b bytes
Thread 3
=
[EMAIL PROTECTED]()
[EMAIL PROTECTED]() + 0xc bytes
[EMAIL PROTECTED]() + 0x84 bytes
[EMAIL PROTECTED]() + 0x12 bytes
nvoglv32.dll!69705b31()
[Frames below may be incorrect and/or missing, no symbols loaded
for nvoglv32.dll]
nvoglv32.dll!696215b0
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hello John, No answers, but I have seen in my own work that adding a new view to an existing (and running) CompositeViewer causes a crash when the CompositeViewer was running in anything other than single-threaded mode when it tries to stop the thread to add the new view (inside CompositeViewer). I had just assumed I was doing something wrong...which may still be the case, but it sounds similar enough to your problem. Thanks for the added data point. Seems similar, though I'm not getting a crash, just what seems like a deadlock after adding a variable number of views. So is the solution to destroy and recreate the CompositeViewer each time I add a view? Adding views should happen seldom enough that it shouldn't cause too much problems, as long as I can keep the settings... I might even be able to just clone the running viewer and then replace it with the cloned one... OK, off to more experimentation... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi JS, I could reproduce any crashes on press 'a' but on pressing escape the code crashed due to a circular reference that your AddViewHandler introduces with its local ref_ptrCompositeViewer. Changing this to observer_ptr fixes the crash on exit. W.r.t crash on add, I've pressed 'a' 20 times in quick succession with any crash. The stopThreading/startThreading is done with addView/removeView now so isn't strictly required - it'll be just a non op doing it twice. I've removed them I still can't reproduce the crash so it does seem to be working OK. One thing to note is that I've merged a threading fix to CompositeViewer's since 2.6. Perhaps this is having an effect, try svn/trunk. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi Robert, Thanks a lot for testing. I could reproduce any crashes on press 'a' but on pressing escape the code crashed due to a circular reference that your AddViewHandler introduces with its local ref_ptrCompositeViewer. Changing this to observer_ptr fixes the crash on exit. Yes of course, I didn't really focus on that as the deadlock is a bigger issue and this is just a quick tester. I've removed them I still can't reproduce the crash so it does seem to be working OK. Weird, I can still get the deadlock, and JP seems to get it too on Linux. I wonder what's different. What threading mode were you running? One thing to note is that I've merged a threading fix to CompositeViewer's since 2.6. Perhaps this is having an effect, try svn/trunk. I am - this example was compiled with SVN as of this Monday. Still getting a deadlock after a variable number of added views. Any other ideas as to what I could be doing wrong? Thanks again, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
On Tue, Nov 18, 2008 at 3:56 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Any other ideas as to what I could be doing wrong? No ideas sorry. Until I can reproduce the problem I'm not really in position to contribute too much. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
