cygserver blocking on semctl(SETVAL) call

[Ethan Tira-Thompson]

> You will likely get better results here if you build the  
> cygwin1.dll locally
> as debug or download cygwin1.dbg for a snapshot cygwin1.dll.  See
> <www.cygwin.com/snapshots>
I think getting a stack trace for each of the threads would probably  
be very useful for tracking this down, so I downloaded the 2006-08-18  
snapshots of both cygwin1-20060818.dll.bz2 and  
cygwin1-20060818.dbg.bz2, decompressed them with bunzip2, stripped  
the timestamp, swapped the original cygwin1.dll with the snapshot  
version, and placed the .dbg alongside it (all in c:/cygwin/bin)

But unfortunately, I still don't get debugging symbols when attaching  
to a process.
Here's a bit of test code I'm running for illustration (test.cc):
#include <iostream>
#include <unistd.h>

using namespace std;

int main() {
	sleep(5);
	cout << "Hello World!" << endl;
	return 0;
}

Compiled with g++ -g test.cc -o test
Pretty straightforward.

I *do* get the symbols when I launch with gdb, e.g. gdb test.exe.   
It's still a little odd though because I can set a breakpoint like  
test.cc:7, and check the stack and see main() listed, but then if I  
step into sleep (or just set a breakpoint on sleep to begin with),  
any stack traces while within cygwin code go back to listing '??' for  
*my* code.  (no main is listed, just a '??' for the bottom stack  
frame).  That's kind of strange.

So this shows the cygwin symbols are there and available at least.  I  
can step through sleep() and get all kinds of fun stuff in winsup.

It's a different story if I attach to a running process however.  If  
I do something like 'gdb test.exe 1824' during that 5 second window,  
and then try to view the stack (which is what I need to do to get the  
stack trace in my main program we're trying to debug, since it forks  
into several processes), then I just get a couple Windows DLL calls  
at the top, and a whole series of '??' for everything that came  
before it.  (Full console dump attached at end)

So, what's up with that?

-ethan

PS First attempt of this email got kicked back because it had a text/ 
html mime type alongside the text/plain.  Oh my god, that's the end  
of the world, let me tell you.
Can't your list server just strip the html version if you dislike  
html so much?  And even so, is HTML really so bad?  Wouldn't it be  
nice to have syntax-highlighted code samples?  *actual* bold text  
instead of ASCII art highlights?  Real bullet-lists that word wrap  
properly?  <blockquote>-wrapped quotes instead of '>' indented messes?
Considering all of the mail programs I've used will automatically  
also send a plain text version for the luddites out there, and even  
so, last I checked even the console based mail readers (e.g. pine)  
can parse HTML, so I don't see what the problem is here.  *shrug*  
Annnnyway...

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygwin-debug.txt
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060828/9a82ec3a/attachment.txt>
-------------- next part --------------


-------------- next part --------------
--
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/