Mail Archives: cygwin/2004/12/30/18:23:44
On Thu, Dec 30, 2004 at 03:15:22PM -0800, David Hinds wrote:
>On Thu, 2 Dec 2004 at 09:36:21 AM -0500, Christopher Faylor wrote:
>
>> Could you try running this under gdb to see if you get more of a clue
>> about where cygwin is dying? The last entry in the snapshot is not
>> necessarily indicative of this.
>
>[ recap: my problem is that on a dual Xeon workstation running XP SP2,
> loading cygwin1.dll seems to crash out with a segfault about 99% of
> the time, but once I can get an instance of any cygwin program going,
> everything works fine after that ]
>
>I've finally gotten a chance to look at this again. I downloaded the
>current snapshot (cygwin-inst-20041227) and tried running 'mount' from
>that package under gdb. The backtrace does not seem helpful, however:
>
>> (gdb) run
>> Starting program: /c/scratch/usr/bin/mount.exe
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to thread 5496.0x15e8]
>> 0x7c810858 in KERNEL32!CreateThread () from /c/WINDOWS/system32/kernel32.dll
>> (gdb) backtrace
>> #0 0x7c810858 in KERNEL32!CreateThread ()
>> from /c/WINDOWS/system32/kernel32.dll
It seems like you only followed some of my instructions:
To debug cygwin:
1) Put the latest version of the dll which works for you
in a directory "foo" along with a copy of gdb.exe.
2) Set the environment variable CYGWIN_TESTING=1 at the windows
prompt.
3) Debug a cygwin application by typing:
c:\foo\gdb /bin/pwd
(do not cd to the foo directory here)
4) Type "run".
5) If you get a SEGV, it is possible that it is just a natural occurrence
of calling BadWritePtr. Type 'continue' a few times to make sure that
the SEGV address does not change.
6) Type "backtrace" and report the results here.
You missed step 5, apparently.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -