Hi Brian,
On 1/26/07, Brian Keener <[EMAIL PROTECTED]> wrote:
> where it call the function osDB::getRealPath on the path name. See
> line number 208 of FileUtils.cpp:
>
> path = getRealPath(path);
Commenting the above line does seem to clear up the Path problem - applications
had
no trouble finding the plugins or the data.
Perhaps the new osgDB::getRealPath() code in
src/osgDB/FileNameUtils.cpp is the source of the problem. The
implementation is:
std::string osgDB::getRealPath(const std::string& path)
{
#ifdef WIN32
TCHAR retbuf[MAX_PATH + sizeof(TCHAR)];
GetFullPathName(path.c_str(), sizeof(retbuf), retbuf, 0);
return std::string(retbuf);
#else
char resolved_path[PATH_MAX];
char* result = realpath(path.c_str(), resolved_path);
if (result) return std::string(resolved_path);
else return path;
#endif
}
So perhaps Cygwin isn't implementing the Windows GetFullPathName code,
and that using realpath would be better instead. Perhaps the #ifdef
could be tweaked so that under Cygwin it compiles the realpath section
instead of the Win32 one.
> Could you get a stack trace for this hang?
I have attached an strace of the osgwindows applications.
I'm afraid I'm not familiar with strace. I couldn't easily spot a
stack trace in the reams of output. I simply want to the know the
call stack at the point of the crash.
Build again GraphicsWindowWin32 but the gdi32 and user32 libs are needed for it
for
Cygwin - so that I guess is why I had to add to OTHER_LIBS.
OTHER_LIBS is probably too general a place to put it - these libs are
only required for windowing code I presume, so it would just be need
for osgViewer and perhaps the examples.
> The exit from osgViewer should be done pretty co-operatively with nice
> gentle requests for threads loops to exit, and code that waits till
> the exit does happen. There might still be cases that aren't well
> handled so it would be worth investigating in the hope that we might
> be able to do things slightly different to help Cygwin limber along.
I am actually rethinking my thoughts now and I am more inclined the above it
what
is happening - adding prints for when destruct(s) occur causes me to think
things
are being destructed out of order and so something gets left hanging. I least
that
is what I am trying to chase now.
I can't really comment much more, threading is heard to debug, next to
impossible when you don't have a machine in front of you that you can
recreate the problem on.
Isolating which apps fail on exit and which ones don't would be useful.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
