From: Michael Schmitz <schmitzmic@gmail.com> To: Finn Thain <fthain@linux-m68k.org>, Andreas Schwab <schwab@linux-m68k.org> Cc: debian-68k@lists.debian.org, linux-m68k@lists.linux-m68k.org Subject: Re: core dump analysis, was Re: stack smashing detected Date: Mon, 3 Apr 2023 10:01:02 +1200 [thread overview] Message-ID: <67f6bc5f-e1fc-64b9-cb3c-1698cf4daf51@gmail.com> (raw) In-Reply-To: <5a5588ca-81c3-3f4c-fd43-c95e90b27939@linux-m68k.org> Hi Finn, On 2/04/23 22:46, Finn Thain wrote: > On Sat, 1 Apr 2023, Andreas Schwab wrote: > >> On Apr 01 2023, Finn Thain wrote: >> >>> So, in summary, the canary validation failed in this case not because >>> the canary got clobbered but because %a3 got clobbered, somewhere >>> between __wait3+24 and __wait3+70 (below). >>> >>> The call to __GI___wait4_time64 causes %a3 to be saved to and restored >>> from the stack, so stack corruption seems to be a strong possibility >>> to explain the change in %a3. >>> >>> But if that's what happened, I'd expect __GI___wait4_time64 to report >>> stack smashing, not __wait3... >> The stask smashing probably didn't fire in __wait4_time64, because it >> hit the saved register area, not the canary (which reside on the >> opposite ends of the stack frame). >> > OK. > > This is odd: > > https://sources.debian.org/src/dash/0.5.12-2/src/jobs.c/?hl=1165#L1165 > > 1176 do { > 1177 gotsigchld = 0; > 1178 do > 1179 err = wait3(status, flags, NULL); > 1180 while (err < 0 && errno == EINTR); > 1181 > 1182 if (err || (err = -!block)) > 1183 break; > 1184 > 1185 sigblockall(&oldmask); > 1186 > 1187 while (!gotsigchld && !pending_sig) > 1188 sigsuspend(&oldmask); > 1189 > 1190 sigclearmask(); > 1191 } while (gotsigchld); > 1192 > 1193 return err; > > Execution of dash under gdb doesn't seem to agree with the source code > above. > > If wait3() returns the child pid then the break should execute. And it > does return the pid (4107) but the while loop was not terminated. Hence > wait3() was called again and the same breakpoint was hit again. Also, the I wonder whether line 1182 got miscompiled by gcc. As err == 4107 it's > 0 and the break clearly ought to have been taken, and the second condition (which changes err) does not need to be examined. Do the same ordering constraints apply to '||' as to '&&' ? What does the disassembly of this section look like? > while loop should have ended after the first iteration because gotsigchild > should have been set by the signal handler which executed before wait3() > even returned... Setting gotsigchild > 0 would cause the while loop to continue, no? The second wait3 call then returns an error (errno ECHILD), leaves gotsigchild clear and exits the loop (returning from waitproc with error, which it shouldn't have). > > ... > (gdb) c > Continuing. > # > # > # x=$(:) > [Detaching after fork from child process 4107] > > Program received signal SIGCHLD, Child status changed. > 0xc00e81b6 in __GI___wait4_time64 (pid=-1, stat_loc=0xeffff87a, options=2, > usage=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:35 > 35 ../sysdeps/unix/sysv/linux/wait4.c: No such file or directory. > (gdb) c > Continuing. > > Breakpoint 3, waitproc (status=0xeffff86a, block=1) at jobs.c:1180 > 1180 jobs.c: No such file or directory. > (gdb) info locals > oldmask = {__val = {1101825, 3844132865, 2072969216, 192511, 4190371840, > 4509697, 3836788738, 1049415681, 3837317121, 3094671359, 4184080384, > 536870943, 717475840, 3485913089, 3836792833, 2072969216, 184321, > 3844141055, 4190425089, 4127248385, 3094659084, 597610497, 4137734145, > 3844079616, 131072, 269156352, 184320, 3878473729, 3844132865, 3094663168, > 3549089793, 3844132865}} > flags = 2 > err = 4107 > oldmask = <optimized out> > flags = <optimized out> > err = <optimized out> > (gdb) print errno > $6 = 2 Is that ENOENT the returned status from the child process? Cheers, Michael > (gdb) c > Continuing. > > Breakpoint 3, waitproc (status=0xeffff86a, block=0) at jobs.c:1180 > 1180 in jobs.c > (gdb) info locals > oldmask = {__val = {1101825, 3844132865, 2072969216, 192511, 4190371840, > 4509697, 3836788738, 1049415681, 3837317121, 3094671359, 4184080384, > 536870943, 717475840, 3485913089, 3836792833, 2072969216, 184321, > 3844141055, 4190425089, 4127248385, 3094659084, 597610497, 4137734145, > 3844079616, 131072, 269156352, 184320, 3878473729, 3844132865, 3094663168, > 3549089793, 3844132865}} > flags = 3 > err = -1 > oldmask = <optimized out> > flags = <optimized out> > err = <optimized out> > (gdb) print errno > $7 = 10 > (gdb)
next prev parent reply other threads:[~2023-04-02 22:01 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4a9c1d0d-07aa-792e-921f-237d5a30fc44.ref@yahoo.com>
[not found] ` <4a9c1d0d-07aa-792e-921f-237d5a30fc44@yahoo.com>
2023-01-30 10:12 ` stack smashing detected Geert Uytterhoeven
2023-01-31 3:05 ` Michael Schmitz
[not found] ` <af524ac9-f5af-e9fb-e33f-0884a0ebfcb6@yahoo.com>
2023-02-01 18:51 ` Michael Schmitz
2023-02-02 7:52 ` Geert Uytterhoeven
[not found] ` <8fb2aa62-dcec-9bd0-b8da-00d9bb4ddaba@yahoo.com>
2023-02-03 0:15 ` Michael Schmitz
2023-02-05 22:19 ` Michael Schmitz
[not found] ` <33d7ea3e-9bd2-16e4-4d9a-f7aa5657a0f7@yahoo.com>
2023-02-07 22:58 ` Michael Schmitz
2023-02-09 3:41 ` Michael Schmitz
[not found] ` <c01e2f1c-425f-478d-918e-cd1fd37e0008@yahoo.com>
[not found] ` <aee359a6-b5e0-fbe2-3988-779f8601f106@gmail.com>
[not found] ` <8042d988-6dd9-8170-60e9-cdf19118440f@yahoo.com>
[not found] ` <a8f06e4b-db28-c8f9-5e21-3ea0f3eebacd@linux-m68k.org>
[not found] ` <bb27b393-3d02-f42c-5c7f-c27d4936ece9@linux-m68k.org>
[not found] ` <37da2ca2-dd99-8417-7cae-a88e2e7fc1b6@yahoo.com>
[not found] ` <30a1be59-a1fd-f882-1072-c7db8734b1f1@gmail.com>
[not found] ` <39f79c2d-e803-d7b1-078f-8757ca9b1238@yahoo.com>
[not found] ` <c47abfdc-31c8-e7ed-1c14-90f68710f25d@gmail.com>
[not found] ` <040ad66a-71dd-001b-0446-36cbd6547b37@yahoo.com>
[not found] ` <5b9d64bb-2adc-20a2-f596-f99bf255b5cc@linux-m68k.org>
[not found] ` <56bd9a33-c58a-58e0-3956-e63c61abe5fe@yahoo.com>
[not found] ` <1725f7c1-2084-a404-653d-9e9f8bbe961c@linux-m68k.org>
2023-03-28 3:37 ` core dump analysis, was " Finn Thain
2023-03-31 3:33 ` Finn Thain
2023-04-01 9:27 ` Finn Thain
2023-04-01 10:11 ` Andreas Schwab
2023-04-02 10:46 ` Finn Thain
2023-04-02 22:01 ` Michael Schmitz [this message]
2023-04-04 0:13 ` Finn Thain
2023-04-04 23:22 ` Michael Schmitz
2023-04-05 2:00 ` Finn Thain
2023-04-07 1:57 ` Michael Schmitz
2023-04-07 4:03 ` dash behaviour, was Re: core dump analysis Finn Thain
2023-04-07 12:10 ` Geert Uytterhoeven
2023-04-08 5:29 ` Finn Thain
2023-04-09 8:30 ` Geert Uytterhoeven
2023-04-09 3:48 ` Michael Schmitz
2023-04-09 4:42 ` Finn Thain
2023-04-09 4:55 ` Michael Schmitz
2023-04-09 7:32 ` Finn Thain
2023-04-10 8:12 ` Michael Schmitz
2023-04-10 9:39 ` kernel behaviour, was Re: dash behaviour Finn Thain
2023-04-11 4:29 ` Michael Schmitz
2023-04-11 4:50 ` Finn Thain
2023-04-11 7:21 ` Geert Uytterhoeven
2023-04-07 12:06 ` core dump analysis, was Re: stack smashing detected Geert Uytterhoeven
2023-04-09 1:56 ` Michael Schmitz
2023-04-11 0:20 ` instrumentation, was Re: core dump analysis Finn Thain
2023-04-11 4:56 ` Michael Schmitz
2023-04-11 5:54 ` Finn Thain
2023-04-11 7:19 ` Geert Uytterhoeven
2023-04-11 8:24 ` Michael Schmitz
2023-04-12 23:22 ` Eero Tamminen
2023-04-15 15:50 ` Eero Tamminen
2023-04-15 21:56 ` Brad Boyer
2023-04-14 9:30 ` core dump analysis, was Re: stack smashing detected Finn Thain
2023-04-16 1:50 ` Michael Schmitz
2023-04-16 6:44 ` Finn Thain
2023-04-17 23:32 ` Michael Schmitz
2023-04-18 2:04 ` Finn Thain
2023-04-18 5:29 ` Michael Schmitz
2023-04-19 1:50 ` Finn Thain
2023-04-19 8:15 ` Michael Schmitz
2023-04-23 7:46 ` Finn Thain
2023-04-23 21:26 ` Michael Schmitz
2023-04-19 10:50 ` reliable reproducer, was Re: core dump analysis Finn Thain
2023-04-19 11:55 ` Geert Uytterhoeven
2023-04-20 1:02 ` Finn Thain
2023-04-20 0:55 ` Michael Schmitz
2023-04-20 2:57 ` Finn Thain
2023-04-20 4:08 ` Michael Schmitz
2023-04-20 5:17 ` Finn Thain
2023-04-20 5:48 ` Finn Thain
2023-04-20 7:34 ` Michael Schmitz
2023-04-20 7:47 ` Finn Thain
2023-04-20 8:23 ` Michael Schmitz
2023-04-20 8:55 ` Finn Thain
2023-04-20 21:58 ` Michael Schmitz
2023-04-21 1:45 ` Michael Schmitz
2023-04-21 5:52 ` Michael Schmitz
2023-04-21 8:30 ` Finn Thain
2023-04-21 9:18 ` Michael Schmitz
2023-04-22 7:54 ` Michael Schmitz
2023-04-22 8:07 ` Andreas Schwab
2023-04-22 8:16 ` Michael Schmitz
2023-04-22 10:12 ` Andreas Schwab
2023-04-22 18:24 ` Michael Schmitz
2023-04-22 18:38 ` Andreas Schwab
2023-04-22 20:06 ` Michael Schmitz
2023-04-22 20:46 ` Andreas Schwab
2023-04-23 1:41 ` Michael Schmitz
2023-04-23 7:37 ` Andreas Schwab
2023-04-23 8:18 ` Michael Schmitz
2023-04-23 8:23 ` Andreas Schwab
2023-04-23 20:19 ` Michael Schmitz
2023-04-23 21:48 ` Andreas Schwab
2023-04-24 3:51 ` Michael Schmitz
2023-04-24 5:46 ` Michael Schmitz
2023-04-23 9:23 ` Finn Thain
2023-04-23 20:43 ` Michael Schmitz
2023-04-24 23:44 ` Finn Thain
[not found] ` <1d9955d2-6016-a238-142a-887f95465dd8@linux-m68k.org>
[not found] ` <4763c8e2-6fb3-eda6-10d0-94ed1d01cd60@gmail.com>
[not found] ` <a5d70bac-bd00-7131-9ca0-18976f539adf@linux-m68k.org>
[not found] ` <b150c146-cade-bcd3-9c34-d99284dcd153@gmail.com>
[not found] ` <c3d2d874-e366-1d3b-71b0-7a089d40308a@linux-m68k.org>
2023-04-25 1:55 ` signal delivery, was Re: reliable reproducer Finn Thain
2023-04-25 2:32 ` Michael Schmitz
2023-04-25 5:59 ` Michael Schmitz
2023-04-26 19:45 ` Michael Schmitz
[not found] ` <1c4fc19f-ad9b-7b8f-6638-8b026fe1280b@linux-m68k.org>
[not found] ` <5ac55169-4916-d671-489f-7eb8fb85d336@gmail.com>
[not found] ` <9544ef26-a444-e186-fb1e-0e914acd36af@gmail.com>
[not found] ` <20de24b3-098d-4603-2768-b0468a4fe772@gmail.com>
[not found] ` <69565abb-1cd6-716e-046e-5a6d69a4e617@linux-m68k.org>
[not found] ` <89cb2211-5f6e-07a2-3149-1ad1ad887265@linux-m68k.org>
[not found] ` <d3d27369-8532-ba69-2463-66b8decbee67@gmail.com>
[not found] ` <4b4eacf2-6934-5563-fb47-04843a77a35c@gmail.com>
2023-04-29 0:28 ` Finn Thain
2023-04-29 0:53 ` Finn Thain
2023-04-29 2:53 ` Michael Schmitz
2023-04-29 5:03 ` Finn Thain
2023-04-29 6:01 ` Michael Schmitz
2023-04-29 6:13 ` Finn Thain
2023-04-29 6:43 ` Michael Schmitz
2023-04-29 6:05 ` Finn Thain
2023-04-29 7:11 ` Andreas Schwab
2023-04-29 7:37 ` Michael Schmitz
2023-04-25 9:26 ` Eero Tamminen
2023-04-25 11:25 ` Andreas Schwab
2023-04-25 19:46 ` Michael Schmitz
2023-04-26 1:54 ` Michael Schmitz
2023-04-26 3:27 ` Finn Thain
2023-04-26 3:56 ` Michael Schmitz
2023-04-26 4:53 ` Finn Thain
2023-04-26 2:02 ` Finn Thain
2023-04-26 4:00 ` Michael Schmitz
2023-04-26 4:42 ` Finn Thain
2023-04-26 9:10 ` Michael Schmitz
2023-04-26 21:48 ` Brad Boyer
2023-04-26 8:31 ` Andreas Schwab
2023-04-25 11:53 ` Andreas Schwab
2023-04-26 1:59 ` Finn Thain
2023-04-25 5:18 ` reliable reproducer, was Re: core dump analysis Michael Schmitz
2023-04-22 9:00 ` Michael Schmitz
2023-04-21 1:15 ` Finn Thain
2023-04-21 1:57 ` Michael Schmitz
2023-04-21 1:39 ` Finn Thain
2023-04-20 6:04 ` Finn Thain
2023-04-20 7:40 ` Michael Schmitz
2023-04-20 7:58 ` Finn Thain
2023-04-02 4:09 ` core dump analysis, was Re: stack smashing detected Michael Schmitz
2023-04-02 9:31 ` Finn Thain
2023-04-03 8:26 ` Michael Schmitz
2023-04-04 4:05 ` Finn Thain
2023-04-04 11:05 ` Finn Thain
2023-04-09 4:02 ` Finn Thain
2023-02-03 23:39 ` Finn Thain
[not found] ` <86badf6e-2cc8-1937-1a2f-45334bb338f4@yahoo.com>
2023-02-05 22:29 ` Debian initramfs/initrd, was " Finn Thain
2023-02-05 23:18 ` John Paul Adrian Glaubitz
[not found] ` <8107e04f-fd60-c6e3-2bad-cc0d99877967@yahoo.com>
2023-02-06 7:52 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67f6bc5f-e1fc-64b9-cb3c-1698cf4daf51@gmail.com \
--to=schmitzmic@gmail.com \
--cc=debian-68k@lists.debian.org \
--cc=fthain@linux-m68k.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox