Mail Archives: cygwin-developers/2002/01/10/16:44:21
We're using cygwin-1.3.6-6 on our build servers and current versions
of just about all the other packages. We get occasional crashes in
cygwin processes during our automated builds, so I decided to debug
them as follows:
1) Build the current CVS repository configured like this:
CFLAGS="-g -O" configure --enable-threadsafe \
--enable-extra-threadsafe-checking --enable-debugging \
--enable-vfork
2) Install the new-cygwin1.dll built above on our build servers as
cygwin1.dll.
3) Put "error_start=c:\cygwin\bin\dumper.exe" in the CYGWIN
environment variable.
4) Run builds until we get a coredump.
5) Debug the coredump with gdb -- "gdb -nw foo.exe foo.exe.core".
However, I ran into a few problems (obviously, or I wouldn't be
sending this message :-):
1) Things run Very Slowly with the new version of cygwin1.dll. If I
had to guess, I'd guess that --enable-extra-threadsafe-checking is
probably the culprit. Can anybody confirm or deny that?
2) To test that things were working as expected, I compiled and ran
this program:
main() {
char *foo = 0;
foo[0] = '\0';
}
It did, indeed, crash and produce the file a.exe.core when I ran
it. However, when I tried to run "gdb -nw a.exe a.exe.core", it
coredumped too. Note that when I run "gdb -nw a.exe" and type
"run", it correctly runs the program and shows me that the program
segfaulted on the assignment line; it apparently only coredumps
when a core file from dumper is specified on the command line. It
also coredumps if I run "gdb -nw a.exe" and then specify "core
a.exe.core".
My next step will be to recompile gdb with debugging symbols and run
gdb under gdb to try to figure out why it's coredumping. Before I go
ahead with that, does anybody have any insights into what I might be
doing wrong or any other suggestions?
Thanks,
jik
- Raw text -