Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Message-ID: <18622738.1194391730839.JavaMail.jira@brutus>
Date: Tue, 6 Nov 2007 15:28:50 -0800 (PST)
From: "Travis Vitek (JIRA)" <jira@apache.org>
To: stdcxx-dev@incubator.apache.org
Subject: [jira] Updated: (STDCXX-625) 0.process test fails with SEGV due to
 stack overflow
In-Reply-To: <30171221.1193793291344.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/STDCXX-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Travis Vitek updated STDCXX-625:
--------------------------------

    Attachment: stdcxx-625.patch

Even the wait_for_child() code in exec.cpp has a timing window failure. If the call to waitpid() is interrupted for any reason other than to report success or timeout, there is a window in which the alarm signal can be missed before the next call to waitpid(). If that happens, then the waitpid() could hang indefintely.

So I'm attaching a new patch that attempts to do something a bit more like wait_for_child(), but I don't really see any reason that I shouldn't use signal() here instead of sigaction(). I only need to register for SIGALRM, and I don't really need to worry if the signal handler is restored or set to default automatically or not.

That said, I'm thinking it is probably better to just use rw_alarm() and let the implementation of that function decide if it is appropriate to call signal() or sigaction(). Unfortunately I'm fuzzy on why we need to use sigaction() instead of signal() in this case, and most specifically on Linux [see comment from exec.cpp:466]. With all this discussion I'm afraid to assume that I know what I'm doing or that my testcases will expose whatever problem is being eluded to, so I've provided an implementation of rw_waitpid() that uses sigaction() on all non EDG C++ configurations.

Input?

2007-11-06  Travis Vitek  <vitek@roguewave.com>

	STDCXX-625
	* process.cpp (rw_waitpid): Rewrite to avoid sleep() and
	signal timing window. Use sigaction() instead of signal()
	where available.

> 0.process test fails with SEGV due to stack overflow
> ----------------------------------------------------
>
>                 Key: STDCXX-625
>                 URL: https://issues.apache.org/jira/browse/STDCXX-625
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: Tests
>    Affects Versions: 4.2
>         Environment: HP-UX or AIX platforms
>            Reporter: Travis Vitek
>            Assignee: Travis Vitek
>            Priority: Minor
>             Fix For: 4.2.1
>
>         Attachments: stdcxx-625.patch, test.cpp
>
>
> It appears that when we re-register for the signal from within the user signal handler the user signal handler is immediately invoked again. This recursion causes a stack overflow and a crash. Here is the stack on AIX....
> sig_handler(int)( = 20), line 528 in "process.cpp"
> sigaction(??, ??, ??) at 0xd01fa358
> signal(??, ??) at 0xd02759a8
> sig_handler(int)( = 20), line 528 in "process.cpp"
> sigaction(??, ??, ??) at 0xd01fa358
> signal(??, ??) at 0xd02759a8
> sig_handler(int)( = 20), line 528 in "process.cpp"
> nsleep(??, ??) at 0xd01fa1d4
> sleep(??) at 0xd02051d4
> unnamed block $b656, line 553 in "process.cpp"
> rw_waitpid(long,int*,int)(pid = 782442, result = 0x2ff226a0, timeout = 5), line 553 in "process.cpp"
> join_test(long,bool)(pid = 782442, should_hang = false), line 51 in "0.process.cpp"
> test_process_create1()(), line 109 in "0.process.cpp"
> run_test(int,char**)(argc = 1, argv = 0x2ff22a60), line 276 in "0.process.cpp"
> rw_vtest(int,char**,const char*,const char*,const char*,int(*)(int,char**),const char*,char*)(argc = 1, argv = 0x2ff22a60, file_name = "/amd/devco/vitek/stdcxx-trunk/tests/self/0.process.cpp", clause = "0.process", comment = "", fun = 0x2000b85c, optstr = "|-child#0 |-timeout#", va = " "), line 1030 in "driver.cpp"
> rw_test(int,char**,const char*,const char*,const char*,int(*)(int,char**),const char*,...)(argc = 1, argv = 0x2ff22a60, fname = "/amd/devco/vitek/stdcxx-trunk/tests/self/0.process.cpp", clause = "0.process", comment = "", testfun = 0x2000b85c, optstr = "|-child#0 |-timeout#", ... = 0x20009608), line 1128 in "driver.cpp"
> main(argc = 1, argv = 0x2ff22a60), line 299 in "0.process.cpp"
> Here is the stack on HP-UX
> #0  sig_handler (No.Identifier=18) at /amd/devco/vitek/stdcxx-trunk/tests/src/process.cpp:529
> #1  <signal handler called>
> #2  0x7b0086c0 in _sigvector+0x10 () from /usr/lib/libc.2
> #3  0x7b00f114 in signalvector+0xac () from /usr/lib/libc.2
> #4  0x7b00f020 in signal+0xa0 () from /usr/lib/libc.2
> #5  0x187fc in sig_handler (No.Identifier=18) at /amd/devco/vitek/stdcxx-trunk/tests/src/process.cpp:529
> #6  <signal handler called>
> #7  0x7b0086c0 in _sigvector+0x10 () from /usr/lib/libc.2
> #8  0x7b00f114 in signalvector+0xac () from /usr/lib/libc.2
> #9  0x7b00f020 in signal+0xa0 () from /usr/lib/libc.2
> #10 0x187fc in sig_handler (No.Identifier=18) at /amd/devco/vitek/stdcxx-trunk/tests/src/process.cpp:529
> #11 <signal handler called>
> #12 0x7b0086c0 in _sigvector+0x10 () from /usr/lib/libc.2
> #13 0x7b00f114 in signalvector+0xac () from /usr/lib/libc.2
> #14 0x7b00f020 in signal+0xa0 () from /usr/lib/libc.2
> #15 0x187fc in sig_handler (No.Identifier=18) at /amd/devco/vitek/stdcxx-trunk/tests/src/process.cpp:529
> #16 <signal handler called>
> #17 0x7b0086c0 in _sigvector+0x10 () from /usr/lib/libc.2
> #18 0x7b00f114 in signalvector+0xac () from /usr/lib/libc.2
> #19 0x7b00f020 in signal+0xa0 () from /usr/lib/libc.2
> #20 0x187fc in sig_handler (No.Identifier=18) at /amd/devco/vitek/stdcxx-trunk/tests/src/process.cpp:529
> #21 <signal handler called>
> #22 0x7b00a160 in __sigtimedwait_sys+0x10 () from /usr/lib/libc.2
> #23 0x7b013c84 in sigtimedwait+0x6c () from /usr/lib/libc.2
> #24 0x7afa2a50 in sleep+0xe8 () from /usr/lib/libc.2
> #25 0x188f0 in rw_waitpid (pid=13825, result=0x7f7f0db0, timeout=5)
>     at /amd/devco/vitek/stdcxx-trunk/tests/src/process.cpp:555
> #26 0x15250 in join_test (pid=13825, should_hang=false) at /amd/devco/vitek/stdcxx-trunk/tests/self/0.process.cpp:51
> #27 0x15424 in test_process_create1 () at /amd/devco/vitek/stdcxx-trunk/tests/self/0.process.cpp:109
> #28 0x159b4 in run_test (argc=1, argv=0x7f7f08d4) at /amd/devco/vitek/stdcxx-trunk/tests/self/0.process.cpp:276
> #29 0x16d1c in rw_vtest (argc=1, argv=0x7f7f08d4, 
>     file_name=0x8e090 "/amd/devco/vitek/stdcxx-trunk/tests/self/0.process.cpp", clause=0x8e528 "0.process", 
>     comment=0x8e08f "", fun=0x4001ed52 <run_test(int, char **)>, optstr=0x8e534 "|-child#0 |-timeout#", va=0x7f7f0a34)
>     at /amd/devco/vitek/stdcxx-trunk/tests/src/driver.cpp:1030
> #30 0x171ec in rw_test (argc=1, argv=0x7f7f08d4, fname=0x8e090 "/amd/devco/vitek/stdcxx-trunk/tests/self/0.process.cpp", 
>     clause=0x8e528 "0.process", comment=0x8e08f "", testfun=0x4001ed52 <run_test(int, char **)>, 
>     optstr=0x8e534 "|-child#0 |-timeout#") at /amd/devco/vitek/stdcxx-trunk/tests/src/driver.cpp:1127
> #31 0x15ad4 in main (argc=1, argv=0x7f7f08d4) at /amd/devco/vitek/stdcxx-trunk/tests/self/0.process.cpp:299

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.