This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: [f]statvfs (was Re: bug in statfs)
At 11:51 AM 12/6/2003 -0500, Nicholas Wourms wrote:
>Corinna wrote:
>
>> On Fri, Dec 05, 2003 at 11:52:48AM -0500, Nicholas Wourms wrote:
>>
>>>DrMingW or running stuff directly inside gdb. Of course, it would be a
>>>good thing if someone could track this down.
>>
>>
>> You have WinME, you're predestined to track it down.
>
>And to some extent I have been trying, but as I'm sure Pierre can point
>out, this is easier said then done.
Actually I am making some progress.
As noted before all I get is a pop up about a fault in cygwin1.dll
After trying numerous times in gdb, I captured something useful.
Apparently the problem happens during DLL_THREAD_DETACH
when few threads are still alive. A threadinfo linked list appears
to be screwed up. Now let me reboot...
Pierre
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread -173475.0xfdabecbd]
0x610271f0 in _threadinfo::remove() (this=0x18dafd94) at
../../../../src/winsup/cygwin/exceptions.cc:180
180 for (t = _last_thread; t && t != this; t = t->prev)
Current language: auto; currently c++
(gdb) info threads
5 thread -173475.0xfffdcae1 0x61003a1e in cygthread::stub2(void*, void*)
(arg=0x610feb70)
at ../../../../src/winsup/cygwin/cygthread.cc:86
* 4 thread -173475.0xfdabecbd 0x610271f0 in _threadinfo::remove()
(this=0x18dafd94)
at ../../../../src/winsup/cygwin/exceptions.cc:180
(gdb) p t
$1 = (_threadinfo *) 0x74fd94
(gdb) p _last_thread
$2 = (_threadinfo *) 0x74fd94
(gdb) p this
$3 = (_threadinfo * const) 0x18dafd94
(gdb) p *t
Cannot access memory at address 0x74fd94
(gdb) bt
#0 0x610271f0 in _threadinfo::remove() (this=0x18dafd94) at
../../../../src/winsup/cygwin/exceptions.cc:180
#1 0x61059f4e in dll_entry (h=0x61000000, reason=3, static_load=0x0) at
../../../../src/winsup/cygwin/init.cc:36
#2 0xbff6df5f in KERNEL32!GlobalUnlock () from /c/WINDOWS/SYSTEM/KERNEL32.DLL
#3 0x61000000 in ?? ()
#4 0x00000003 in ?? ()