Re: crash on watch directory.

windows is a red-herring. This is a linux program running on linux,
compiled on linux with linux tools.

The windows alike function names and stuff are there presumably because
the "watch directory for music" feature was added to the windows version
first.

I've tried stepping through the function in the debugger, and don't
understand what could be different between the other uses of
FindFirstFile (e.g. looking for themes, plugins, and the initial scan of
MyMusic) which all work fine, and the subsequent scans of MyMusic which
barfs. 

It is a segfault btw.

On Tue, 2003-09-02 at 17:09, Thomas Kimpton wrote:
> > 
> > I am still seeing zinf die when it scans the MyMusic directory. I
> can't for the life of me figure out why.
> > 
> > #0  0x401de0e5 in mallopt () from /lib/libc.so.6
> > #1  0x401dd9da in mallopt () from /lib/libc.so.6
> > #2  0x401dd439 in calloc () from /lib/libc.so.6
> > #3  0x4020b439 in opendir () from /lib/libc.so.6
> > #4  0x080c2e04 in FindFirstFile(char*, WIN32_FIND_DATA*)
> (lpFileName=0x41acc74c "/home/enxrah/MyMusic/*",
> >     lpFindFileData=0xbe1fe9cc) at src/win32impl.cpp:93
> > #5  0x0808c227 in MusicCatalog::DoSearchMusic(char*, bool)
> (this=0x80ee040, path=0x41a7dc64 "/home/enxrah/MyMusic",
> >     bSendMessages=false) at src/musiccatalog.cpp:884
> > #6  0x0808bf09 in MusicCatalog::DoSearchPaths(std::vector<std::string,
> > std::allocator<std::string> >&, bool) (
> >     this=0x80ee040, pathList=@0x865184c, bSendMessages=false) at
> src/musiccatalog.cpp:854 #7  0x0808bd99 in
> MusicCatalog::musicsearch_thread_function(void*)
> > (arg=0x8651848) at src/musiccatalog.cpp:835
> > #8  0x080b9189 in pthreadThread::InternalThreadFunction()
> > (this=0x8181848) at src/pthreadthread.cpp:71
> > #9  0x080b913a in pthreadThread::internalThreadFunction(void*)
> > (arg=0x8181848) at src/pthreadthread.cpp:60
> > #10 0x400368be in pthread_start_thread () from /lib/libpthread.so.0
> #11 0x4003692d in pthread_start_thread_event () from
> /lib/libpthread.so.0 #12 0x4023a547 in clone () from /lib/libc.so.6
> > 
> 
> Robert,
> 
> I'm going out on a limb here, not being familiar with windows
> program execution, but, by examining argument addresses in
> this stack trace it looks like the lpFindFileData may be an
> errant pointer... other data pointers seem to be in the
> 0x8?????? or 0x4??????? areas, while the lpFindFileData is
> 0xbe1fe9cc(path may also be errant...).
> 
> Hmm... is this a cygwin compilation? I notice /lib/libc.so.6
> and WIN32_FIND_DATA. What cond of crash are you seeing? i.e.
> segmentation violation, etc.? (I'm more familiar with linux/
> mac/java than windows :-).
> 
> 
> Tom.
> 
> 
> ----
> "You don't want to sail a ship over an erupting volcano," said Jennifer
> Reynolds, chief expedition scientist and a University of Alaska marine
> geologist. 
-- 
+-------------------------------------+
| "It's only a trap if you don't take |
| a ladder with you to get out of it" |
| 		-S Ring, Bath Uni     |
|                                     |
| [email protected]                   |
| http://www.nott.ac.uk/~enxrah       |
+-------------------------------------+





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf