Re: signal delivery problem (with pthreads)
On Wed, 22 Sep 2004 13:57:26 +0100, Dave Korn wrote: So could someone who got the _successful_ run of sig_bug.exe with recently (1.5.7-1) releases or snapshots of cygwin1.dll send it (sig_bug.exe) to my personal e-mail? Well, here you go; source as well, just in case you have more than one version of your testcase lying around, so you know exactly what I was compiling. Thanks to Dave Korn for his copy of sb.exe. Well, it has been crashed too. Almost all the time (at least for me). With 1.5.11-1 and 20040924. And once with 1.5.7-1 :-[ ] , which I've never seen before. After that I'm feeling doubts about right of my doings. :) Please note, I've executed sb.exe from cmd.exe, not from bash/ash/etc. And I've placed sb.exe on diskette(!) and cygwin1.dll in the current directory on hard disk. In case of placing sb.exe with cygwin1.dll on hard disk I have (almost) never got the stackdump file or it has only the first line. The contents of sb.exe.stackdump (with 1.5.11-1): Exception: STATUS_ACCESS_VIOLATION at eip=0001 eax=001F ebx=4155835A ecx=00CCF0C0 edx=001F esi=0001 edi=00CCF040 ebp=00CCF058 esp=00CCF020 program=a:\sb.exe, pid 120, thread unknown (0x7D) cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023 Stack trace: Frame Function Args 00CCF058 0001 (0003, 10021380, 00CCF0A8, 610A940A) 00CCF068 004011AE (, , , ) 00CCF0A8 610A940A (10021380, 00CCF0E0, 610A9390, ) 00CCF0D8 61003E84 (, , , ) 00CCFFA8 61003E3A (, , , ) End of stack trace Maybe I need to build my own version of cygwin1.dll with debug information turned on but I have never done it before. WBR, Valery -- 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/
RE: signal delivery problem (with pthreads)
-Original Message- From: cygwin-owner On Behalf Of Valery A. Frolov Sent: 21 September 2004 22:52 I've checked it and got the same bad result (crash) on 2000, XP and Win98. I've installed cygwin bundle for compilation of sig_bug.c on XP, compiled sig_bug.c to sig_bug.exe and ran it. Nothing was changed - crash. So could someone who got the _successful_ run of sig_bug.exe with recently (1.5.7-1) releases or snapshots of cygwin1.dll send it (sig_bug.exe) to my personal e-mail? Well, here you go; source as well, just in case you have more than one version of your testcase lying around, so you know exactly what I was compiling. [Actually, on second thoughts, I'm going to send this post to the list, so I'll send you the files separately. There have been further developments while I was writing this post that I thought the list should be informed about.] A funny thing happened to me on the way to email this to you, however: I thought I'd try running it again, and this time it crashed for the first time! However it still works fine almost all the time when run directly from the command line, but I've noticed that when I run it in a loop with for i in 1 2 3 4 5 6 7 8 9 10 ; do ./sb.exe ; done it crashes more often than not! This is interesting, and suggests an interaction with process spawn/forking. The contents of the .stackdump file are fairly interesting too: Exception: STATUS_ACCESS_VIOLATION at eip=0085F030 eax=001F ebx= ecx=77E75A65 edx=001F esi=41516044 edi=0004 ebp=0086 esp=0085F004 program=C:\artimi.src\davek\test\pthread\sb.exe, pid 2352, thread unknown (0x208) cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023 Stack trace: Frame Function Args 0086 0085F030 (0001, BC5D1B48, , 0001000C) End of stack trace This is very strange indeed. The eip is in between ebp and esp; in other words, we're executing on the stack! And look at the value in ecx: that happens to be the ret instruction at the end of KERNEL32!IsBadWritePtr. _Very_ interesting. Hmm, now I've finally got it to crash under insight! Although the stack (or perhaps only the stack pointer) has been somewhat trashed, I can see enough of it... (gdb) info registers eax0x1f 31 ecx0x77e75a65 2011650661 edx0x1f 31 ebx0x -1 esp0xd5f004 0xd5f004 ebp0xd6 0xd6 esi0x415162eb 1095852779 edi0x4 4 eip0xd5f030 0xd5f030 eflags 0x10216 66070 cs 0x1b 27 ss 0x23 35 ds 0x23 35 es 0x23 35 fs 0x38 56 gs 0x0 0 (gdb) info frame Stack level 0, frame at 0xd5f008: eip = 0xd5f030; saved eip 0x0 Arglist at 0xd5f000, args: Locals at 0xd5f000, Previous frame's sp is 0xd5f008 Saved registers: eip at 0xd5f004 (gdb) frame #0 0x00d5f030 in ?? () (gdb) x/64xw $esp-0x80 0xd5ef84: 0x00d5f208 0x61117310 0x00401090 0x00d5efcc 0xd5ef94: 0x000907d4 0x00160003 0x00d5efbc 0x610e2b47 0xd5efa4: 0x61117310 0x00401090 0x00d5efc8 0x00d6 0xd5efb4: 0x 0x001f 0x00d6 0x00401163 0xd5efc4: 0x00401090 0x0001 0x000f 0xfffefeff 0xd5efd4: 0x2000 0x00d5f00c 0x00d5f00c 0x6108e0bc 0xd5efe4: 0x001e 0x 0x0004 0x 0xd5eff4: 0x415162eb 0x0004 0x00d6 0x00d5f030 0xd5f004: 0x 0x0246 0x00d5f048 0x 0xd5f014: 0x00d5ef84 0x00d5ef84 0x00d5ef84 0x00d5f030 0xd5f024: 0x0002 0x 0x 0x0003 0xd5f034: 0x 0x00d5f048 0x0a053c30 0x0a053c88 0xd5f044: 0x0a053c30 0x00d5f058 0x004011ae 0x0003 0xd5f054: 0x0a053c30 0x00d5f098 0x610a97da 0x 0xd5f064: 0x 0x 0x 0x0001 0xd5f074: 0x 0x 0x 0x Right, what interesting values do we find there? 0x61117310 is in the cygwin dll's data area, somewhere above reent_data, and what do we find there? (gdb) x/xw 0x61117310 0x61117310 reent_data+720:0x0a053cb8 (gdb) x/s 0x0a053cb8 0xa053cb8: select was interrupted 1 times\n Ok! It's printf's output buffer! That ties in with that 0x610e2b47 which is the return address from the call within printf to vfprintf. Next, that 0x00401090 gets there because of this code in my_sleep: 0x00401153 my_sleep+147: mov%esi,0x4(%esp,1) 0x00401157 my_sleep+151: movl $0x401090,(%esp,1) 0x0040115e my_sleep+158: call 0x401710 printf 0x00401163 my_sleep+163: jmp0x40114b my_sleep+139 (gdb) x/s 0x401090 0x401090 sig_hnd+48: select was interrupted %d
Re: signal delivery problem (with pthreads)
Maybe the operating system is the essence. I've always tried it on NT 4.0 WS SP6a+hotfixes. Tomorrow I'll check it (the same executable) on 2000/XP. I've checked it and got the same bad result (crash) on 2000, XP and Win98. I've installed cygwin bundle for compilation of sig_bug.c on XP, compiled sig_bug.c to sig_bug.exe and ran it. Nothing was changed - crash. So could someone who got the _successful_ run of sig_bug.exe with recently (1.5.7-1) releases or snapshots of cygwin1.dll send it (sig_bug.exe) to my personal e-mail? And please, specify your arguments for gcc, version of gcc, version of cygwin1.dll and version of OS, for example: * gcc -O2 -s -o sig_bug.exe sig_bug.c -lpthread * gcc version 3.3.3-3 * cygwin1.dll from snapshot of 20040920 * Windows NT Workstation 4.0 SP6a+ I'll try received sig_bug.exe with my cygwin1.dll in my environment to distinguish a (possible) cygwin1.dll issue from a compilation (gcc/binutils) issue. Thanks. WBR, Valery -- 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/
Re: signal delivery problem (with pthreads)
On Fri, Sep 17, 2004 at 10:08:31AM +0100, Dave Korn wrote: No SEGV for me. -lpthread didn't seem necessary. I'm using a version of the cygwin1.dll built from CVS sources on 20041407. Wow, that's a lot more advanced than any snapshot I've seen. I'm curious to know what version it reports. If, for instance, it says 1.5.23s, we'll have advance warning that things will be quite busy for the rest of this year. :) More seriously, did you try it more than once? I'm using gcc 3.4.1 and the 20040907 snapshot and seeing intermittent SEGVs with the test program. Several times I got select was interrupted 4202497 times, indicating that something bad is happening to the thread's stack. I did notice that the test program has erroneous calls to perror, since the pthread_ routines don't set errno, but fixing those didn't affect the results. -- 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/
Re: signal delivery problem (with pthreads)
On Sun, Sep 19, 2004 at 11:17:28PM -0700, Yitzchak Scott-Thoennes wrote: On Fri, Sep 17, 2004 at 10:08:31AM +0100, Dave Korn wrote: No SEGV for me. -lpthread didn't seem necessary. I'm using a version of the cygwin1.dll built from CVS sources on 20041407. did you try it more than once? I'm using gcc 3.4.1 and the 20040907 snapshot and seeing intermittent SEGVs with the test program. Several times I got select was interrupted 4202497 times, indicating that something bad is happening to the thread's stack. FWIW, I tried it ten times without error. I have it running in a loop now. If it dies, I'll fix the problem. 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/
RE: signal delivery problem (with pthreads)
-Original Message- From: cygwin-owner On Behalf Of Christopher Faylor Sent: 20 September 2004 15:36 On Sun, Sep 19, 2004 at 11:17:28PM -0700, Yitzchak Scott-Thoennes wrote: On Fri, Sep 17, 2004 at 10:08:31AM +0100, Dave Korn wrote: No SEGV for me. -lpthread didn't seem necessary. I'm using a version of the cygwin1.dll built from CVS sources on 20041407. did you try it more than once? I'm using gcc 3.4.1 and the 20040907 snapshot and seeing intermittent SEGVs with the test program. Several times I got select was interrupted 4202497 times, indicating that something bad is happening to the thread's stack. FWIW, I tried it ten times without error. Ditto. I have it running in a loop now. If it dies, I'll fix the problem. Not ditto! :) cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: signal delivery problem (with pthreads)
On Mon, 20 Sep 2004 10:35:48 -0400, Christopher Faylor wrote: FWIW, I tried it ten times without error. I have it running in a loop now. If it dies, I'll fix the problem. But I had _no_ one successful run at all. Maybe the operating system is the essence. I've always tried it on NT 4.0 WS SP6a+hotfixes. Tomorrow I'll check it (the same executable) on 2000/XP. WBR, Valery -- 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/
RE: signal delivery problem (with pthreads)
-Original Message- From: cygwin-owner On Behalf Of Valery A. Frolov Sent: 16 September 2004 20:15 And after while I've got (IMHO) a little test source (attached) to reproduce the problem. Can anyone confirm this problem? So, after week of silence I can make the decision that this problem has been happened only for me (because no one has confirmed it). Anyway, many many thanks for all Cygwin's developers for their great job. Let source be with you, Cygwin! (c) almost Star Wars. :) WBR, Valery Ok, here ya go, I guess if you went to the trouble of http://cygwin.com/acronyms#PPAST 'ing, I can take a couple of minutes to check it out for you! :) [EMAIL PROTECTED] /test/pthread gcc -O2 -g -o sb sig_bug.c [EMAIL PROTECTED] /test/pthread ./sb new thread start got signal 30 OK, press any key to exit... got signal 30 got signal 30 select was interrupted 1 times [EMAIL PROTECTED] /test/pthread gcc -O2 -g -o sb sig_bug.c -lpthread [EMAIL PROTECTED] /test/pthread ./sb new thread start got signal 30 OK, press any key to exit... got signal 30 got signal 30 select was interrupted 1 times [EMAIL PROTECTED] /test/pthread No SEGV for me. -lpthread didn't seem necessary. I'm using a version of the cygwin1.dll built from CVS sources on 20041407. cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: signal delivery problem (with pthreads)
And after while I've got (IMHO) a little test source (attached) to reproduce the problem. Can anyone confirm this problem? So, after week of silence I can make the decision that this problem has been happened only for me (because no one has confirmed it). Anyway, many many thanks for all Cygwin's developers for their great job. Let source be with you, Cygwin! (c) almost Star Wars. :) WBR, Valery -- 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/
Re: signal delivery problem (with pthreads)
Hello, On Mon, 30 Aug 2004 13:43:50 +0300, Valery A. Frolov wrote: And after while I've got (IMHO) a little test source (attached) to reproduce the problem. Can anyone confirm this problem? I've tested my testcase source (see previous letter) with cygwin1.dll 1.5.11-1, gcc 3.3.3-3, binutils-20040725-2 and the problem is _still_ exist (at least for me). WBR, Valery -- 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/
signal delivery problem (with pthreads)
Hello,
In short:
First signal delivery on call of pthread_kill(tid, SIGUSR1) works fine
but second one delivers signal with _delay_ and _twice_, and then my
own daemon crash. This is on cygwin1.dll 1.5.10-3 and snapshot of
2004-08-21. But on cygwin1.dll 1.5.7-1 all works _fine_ and _long_ time.
In detail:
(Sorry for my bad English.)
(And sorry for long letter.)
(And much more sorry if this is not appropriate place to ask this question.)
I'm writing a daemon. Multi-threaded and TCP/IP-oriented. And it works.
On Linux and FreeBSD. And on cygwin 1.5.7-1. But there is a problem
which I'm currently trying to solve: one of the servicing client thread
hangs up with 100% CPU usage in random time periods (but with probability
nearly equal to 1) and do not response to wakeup signals.
The first investigation brought me an idea that the problem is lying in
select() call in cygwin implementation. (I have only one socket in
select() call and nothing more.) But maybe I'm wrong.
Anyway, in that moment I made the decision to update cygwin1.dll because
my cygwin1.dll 1.5.7-1 is too old and maybe a newer version solves my
problem. I got 1.5.10-3 and... my daemon crashed :( on very simple action.
I had never seen something like this with 1.5.7-1.
Then I got the (latest on that moment) snapshot of cygwin1.dll -
2004-08-21. And my daemon crashed again with same symptoms.
gdb 2003-09-20-cvs (cygwin-special) didn't help because it received
SIGSEGV in KERNEL32!IsBadWritePtr on my daemon run before the piece
of code with problem was executed.
But strace (cygwin) 1.21 gave some interesting results.
Here is some data and logs.
$ strace -o strace7.log -t -m sigp yolopd -l yolopd7.log
$ strace -o straceB.log -t -m sigp yolopd -l yolopdB.log
yolopd7.log (1.5.7-1) and yolopdB.log (snapshot 20040821) are
my daemon logs. Just in case.
SIGUSR1 is used by main thread to awake other sleeping threads which
perform some actions.
The SIGUSR1 handler is very simple:
static void handler_sigusr1(int sig)
{
#ifdef DEBUG
log_msg(got SIGUSR1);
#endif
// do nothing, only for exit from sleep()
}
$ grep -i sig yolopd7.log
2004-08-27 13:03:41 yolopd[195]: setting signal handlers done.
2004-08-27 13:03:53 yolopd[195]: ATM001: send SIGUSR1 (refresh).
2004-08-27 13:03:53 yolopd[195]: got SIGUSR1.
2004-08-27 13:04:24 yolopd[195]: ATM001: send SIGUSR1 (refresh).
2004-08-27 13:04:24 yolopd[195]: got SIGUSR1.
[...and then normal exit...]
$ grep -i sig yolopdB.log
2004-08-27 13:01:35 yolopd[149]: setting signal handlers done.
2004-08-27 13:01:50 yolopd[149]: ATM001: send SIGUSR1 (refresh).
2004-08-27 13:01:50 yolopd[149]: got SIGUSR1.
2004-08-27 13:01:59 yolopd[149]: ATM001: send SIGUSR1 (refresh).
2004-08-27 13:02:20 yolopd[149]: got SIGUSR1.
2004-08-27 13:02:20 yolopd[149]: got SIGUSR1. -- twice!
[...immediate crash...]
$ ls -l strace?.log
-rw-r--r--1 Valery None 6277 Aug 27 13:04 strace7.log
-rw-r--r--1 Valery None 171388 Aug 27 13:02 straceB.log
Compare the size of strace log files! :-[ ]
$ grep -c pending strace?.log
strace7.log:5
straceB.log:679 -- !!!
$ grep -c signal.*not delivered strace?.log
strace7.log:0
straceB.log:6 -- !!!
$ grep -E '(arriv|returning.*signal 30)' strace7.log
13:03:53 [sig] yolopd 195 _threadinfo::interrupt_setup: armed signal_arrived 0x60, sig
30, res 1
13:03:53 [main] yolopd 195 reset_signal_arrived: reset signal_arrived
13:03:53 [unknown (0x6A)] yolopd 195 sig_send: returning 0x0 from sending signal 30
13:04:24 [sig] yolopd 195 _threadinfo::interrupt_setup: armed signal_arrived 0x60, sig
30, res 1
13:04:24 [main] yolopd 195 reset_signal_arrived: reset signal_arrived
13:04:24 [unknown (0x6A)] yolopd 195 sig_send: returning 0x0 from sending signal 30
$ grep -E '(arriv|returning.*signal 30)' straceB.log
13:01:50 [sig] yolopd 149 _cygtls::interrupt_setup: armed signal_arrived 0x9C, sig 30,
res 1
13:01:50 [unknown (0xC3)] yolopd 149 sig_send: returning 0x0 from sending signal 30
13:01:51 [unknown (0xC8)] yolopd 149 reset_signal_arrived: reset signal_arrived
13:02:00 [unknown (0xC3)] yolopd 149 sig_send: returning 0x0 from sending signal 30
13:02:20 [unknown (0xC8)] yolopd 149 reset_signal_arrived: reset signal_arrived
13:02:20 [sig] yolopd 149 _cygtls::interrupt_setup: armed signal_arrived 0x9C, sig 30,
res 1
13:02:20 [unknown (0xC8)] yolopd 149 reset_signal_arrived: reset signal_arrived
Two things which I've found out in strace?.log.
First. In strace7.log exactly one reset_signal_arrived record after
each armed signal. In straceB.log for first signal there is _two_
reset_signal_arrived records with ~30 seconds interval.
Second. In strace7.log reset_signal_arrived record is present _before_
returning 0x0 from sending signal 30. In straceB.log - _after_.
Maybe I'm saying nonsense and problem is placed in my daemon code
but not in cygwin but...
Whole trace files (strace7.log straceB.log) are attached to this letter.
I can't make small source code
Re: signal delivery problem (with pthreads)
Whole trace files (strace7.log straceB.log) are attached to this letter.
Heh... Forgot attach it.
WBR,
Valery
13:03:41 [main] yolopd 161 sigproc_init: process/signal handling enabled(1)
13:03:41 [main] yolopd 161 wait_for_sigthread: wait_sig_inited 0x54
13:03:41 [main] yolopd 161 subproc_init: started wait_subproc thread
13:03:41 [main] yolopd 161 proc_subproc: args: 1, 2239944
13:03:41 [main] yolopd 161 proc_subproc: added pid 195 to wait list, slot 0, winpid
0xC3, handle 0x128
13:03:41 [main] yolopd 161 proc_subproc: returning 1
13:03:41 [proc] yolopd 161 wait_subproc: starting
13:03:41 [proc] yolopd 161 wait_subproc: looping
13:03:41 [main] yolopd 195 fork_child: hParent 0x68, child 1 first_dll 0x0, load_dlls 0
13:03:41 [main] yolopd 195 sigproc_init: process/signal handling enabled(801)
13:03:41 [main] yolopd 195 wait_for_sigthread: wait_sig_inited 0x48
13:03:41 [main] yolopd 195 sigaction: signal 15, newact 0x0, oldact 0x2233F0
13:03:41 [main] yolopd 195 sigaction: signal 15, newact 0x2233F0, oldact 0x0
13:03:41 [main] yolopd 195 sigaction: signal 2, newact 0x0, oldact 0x2233F0
13:03:41 [main] yolopd 195 sigaction: signal 2, newact 0x2233F0, oldact 0x0
13:03:41 [main] yolopd 195 sigaction: signal 30, newact 0x0, oldact 0x2233F0
13:03:41 [main] yolopd 195 sigaction: signal 30, newact 0x2233F0, oldact 0x0
13:03:41 [main] yolopd 195 sigaction: signal 31, newact 0x0, oldact 0x2233F0
13:03:41 [main] yolopd 195 sigaction: signal 31, newact 0x2233F0, oldact 0x0
13:03:41 [main] yolopd 195 sigaction: signal 1, newact 0x0, oldact 0x2233F0
13:03:41 [main] yolopd 195 sigaction: signal 1, newact 0x2233F0, oldact 0x0
13:03:41 [main] yolopd 195 sigaction: signal 13, newact 0x0, oldact 0x2233F0
13:03:41 [main] yolopd 195 sigaction: signal 13, newact 0x2233F0, oldact 0x0
13:03:41 [main] yolopd 195 sig_send: sendsig 0xE8, pid 195, signal -13, its_me 1
13:03:41 [main] yolopd 195 sig_send: wakeup 0xC0
13:03:41 [sig] yolopd 195 wait_sig: signalled 0xC0
13:03:41 [main] yolopd 195 sig_send: Waiting for pack.wakeup 0xC0
13:03:41 [main] yolopd 195 sig_send: returning 0x0 from sending signal -13
13:03:41 [main] yolopd 195 set_signal_mask: oldmask 0x0, newmask 0x0, mask_bits 0x0
13:03:41 [main] yolopd 195 set_signal_mask: not calling sig_dispatch_pending
13:03:41 [main] yolopd 195 handle_sigsuspend: oldmask 0x0, newmask 0x0
13:03:42 [main] yolopd 161 sigproc_terminate: entering
13:03:42 [sig] yolopd 161 wait_sig: done
13:03:42 [main] yolopd 161 proc_terminate: nchildren 1, nzombies 0
13:03:42 [main] yolopd 161 proc_subproc: args: 3, 1
13:03:42 [main] yolopd 161 proc_subproc: clear waiting threads
13:03:42 [main] yolopd 161 proc_subproc: finished clearing
13:03:42 [main] yolopd 161 proc_subproc: returning 1
13:03:42 [main] yolopd 161 proc_terminate: 195(195) closed child handle
13:03:42 [main] yolopd 161 proc_terminate: leaving
13:03:42 [main] yolopd 161 do_exit: 161 == pgrp 161, send SIG{HUP,CONT} to stopped
children
13:03:42 [main] yolopd 161 kill_pgrp: pid 161, signal -1
13:03:42 [proc] yolopd 161 wait_subproc: looping
13:03:42 [proc] yolopd 161 wait_subproc: done
13:03:42 [main] yolopd 161 _pinfo::exit: Calling ExitProcess 0
13:03:53 [unknown (0x6A)] yolopd 195 sig_send: sendsig 0xE8, pid 195, signal 30,
its_me 1
13:03:53 [unknown (0x6A)] yolopd 195 sig_send: wakeup 0x140
13:03:53 [sig] yolopd 195 sig_handle: signal 30 processing
13:03:53 [sig] yolopd 195 sig_handle: signal 30, about to call 0x401088
13:03:53 [sig] yolopd 195 proc_subproc: args: 3, 1
13:03:53 [sig] yolopd 195 proc_subproc: clear waiting threads
13:03:53 [sig] yolopd 195 proc_subproc: finished clearing
13:03:53 [sig] yolopd 195 proc_subproc: returning 1
13:03:53 [sig] yolopd 195 _threadinfo::interrupt_setup: armed signal_arrived 0x60, sig
30, res 1
13:03:53 [sig] yolopd 195 setup_handler: interrupted known cygwin routine
13:03:53 [sig] yolopd 195 setup_handler: signal 30 delivered
13:03:53 [sig] yolopd 195 sig_handle: returning 1
13:03:53 [sig] yolopd 195 wait_sig: signalled 0x140
13:03:53 [main] yolopd 195 reset_signal_arrived: reset signal_arrived
13:03:53 [main] yolopd 195 set_signal_mask: oldmask 0x0, newmask 0x2000, mask_bits
0x0
13:03:53 [main] yolopd 195 set_signal_mask: not calling sig_dispatch_pending
13:03:53 [main] yolopd 195 set_signal_mask: oldmask 0x2000, newmask 0x0, mask_bits
0x2000
13:03:53 [main] yolopd 195 set_signal_mask: oldmask 0x0, newmask 0x0, mask_bits 0x0
13:03:53 [main] yolopd 195 set_signal_mask: not calling sig_dispatch_pending
13:03:53 [main] yolopd 195 handle_sigsuspend: oldmask 0x0, newmask 0x0
13:03:53 [unknown (0x6A)] yolopd 195 sig_send: Waiting for pack.wakeup 0x140
13:03:53 [unknown (0x6A)] yolopd 195 sig_send: returning 0x0 from sending signal 30
13:04:24 [unknown (0x6A)] yolopd 195 sig_send: sendsig 0xE8, pid 195, signal 30,
its_me 1
13:04:24 [unknown (0x6A)] yolopd 195 sig_send: wakeup 0x1E8
13:04:24 [sig] yolopd 195 sig_handle: signal 30 processing
13:04:24 [sig] yolopd 195 sig_handle: signal
Re: signal delivery problem (with pthreads)
On Fri, Aug 27, 2004 at 09:11:56PM +0300, Valery A. Frolov wrote: In short: First signal delivery on call of pthread_kill(tid, SIGUSR1) works fine but second one delivers signal with _delay_ and _twice_, and then my own daemon crash. This is on cygwin1.dll 1.5.10-3 and snapshot of 2004-08-21. But on cygwin1.dll 1.5.7-1 all works _fine_ and _long_ time. In detail: (Sorry for my bad English.) (And sorry for long letter.) (And much more sorry if this is not appropriate place to ask this question.) Sorry, but if this is really a problem, you're going to have to provide a simple test case which reproduces it. Providing a description of the symptoms is not going to do it and neither is unsolicited strace output. -- 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/
