Menu
▾
▴
user-mode-linux-devel
|
From: Jeff D. <jd...@ka...> - 2000-10-08 04:28:50
|
Thank you!
I've been waiting for someone to send me that stack. There aren't any real
smoking guns there. I'm guessing that the difference between your laptop and
the machine it works on is that your laptop is running a fairly recent kernel
(2.4.0-testx) and the other isn't. The sigcontext struct greatly increased in
size (to ~800 bytes IIRC) to accomodate the MMX registers or something. There
are three signals on your stack, so those frames by themselves are taking up
half the stack page.
Anyway, the patch below removes 256 bytes from the set_signals frame. It
ought to alleviate things a bit. I'll be looking for other things I can do,
as well. Let me know how it works for you.
Jeff
--- arch/um/kernel/signal_user.c~ Thu Sep 14 17:00:08 2000
+++ arch/um/kernel/signal_user.c Sun Oct 8 00:21:29 2000
@@ -45,26 +45,29 @@
int set_signals(int enable)
{
- sigset_t mask, unmask, old;
+ sigset_t mask;
+ int ret;
check_stack_overflow(&enable);
+ sigprocmask(SIG_BLOCK, NULL, &mask);
+ ret = enable_mask(&mask);
sigemptyset(&mask);
- sigemptyset(&unmask);
- if(enable & (1 << SIGIO_BIT)) sigaddset(&unmask, SIGIO);
- else sigaddset(&mask, SIGIO);
+ if(enable & (1 << SIGIO_BIT)) sigaddset(&mask, SIGIO);
if(enable & (1 << SIGVTALRM_BIT)){
- sigaddset(&unmask, SIGVTALRM);
- sigaddset(&unmask, SIGALRM);
+ sigaddset(&mask, SIGVTALRM);
+ sigaddset(&mask, SIGALRM);
}
- else {
+ if(sigprocmask(SIG_UNBLOCK, &mask, NULL) < 0)
+ panic("Failed to enable signals");
+ sigemptyset(&mask);
+ if((enable & (1 << SIGIO_BIT)) == 0) sigaddset(&mask, SIGIO);
+ if((enable & (1 << SIGVTALRM_BIT)) == 0){
sigaddset(&mask, SIGVTALRM);
sigaddset(&mask, SIGALRM);
}
- if(sigprocmask(SIG_BLOCK, &mask, &old) < 0)
- panic("Failed to change signal mask");
- if(sigprocmask(SIG_UNBLOCK, &unmask, NULL) < 0)
- panic("Failed to change signal mask");
- return(enable_mask(&old));
+ if(sigprocmask(SIG_BLOCK, &mask, NULL) < 0)
+ panic("Failed to block signals");
+ return(ret);
}
/*
|
|
From: Robert R. <ip...@di...> - 2000-10-10 05:42:43
|
I have no idea if this is how you do it but anyways. Program received signal SIGSEGV, Segmentation fault. 0x10038490 in ?? () (gdb) handle SIGSEGV pass nostop noprint Signal Stop Print Pass to program Description SIGSEGV No No Yes Segmentation fault (gdb) continue Continuing. warning: Couldn't get registers. warning: Couldn't get registers. warning: Couldn't get registers. ptrace: Operation not permitted. warning: Couldn't get registers. warning: Couldn't get registers. warning: Couldn't get registers. 0x100b2744 in ?? () (gdb) -- "We are all so much together and yet we are all dying of loneliness."--A.Schweitzer |
|
From: Robert R. <ip...@di...> - 2000-10-11 02:51:24
|
Sorry about that I totally forgot I stripped it. 140000e att 1 b start_kernel c GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) att 1 Attaching to program: /home/rendler/uml/linux, Pid 1 0x100b2fe1 in kill () at eth_kern.c:307 307 } (gdb) b start_kernel Breakpoint 1 at 0x100f37b9: file init/main.c, line 515. (gdb) c Continuing. Breakpoint 1, start_kernel () at init/main.c:515 515 setup_arch(&command_line); (gdb) handle SIGSEGV pass nostop noprint Signal Stop Print Pass to program Description SIGSEGV No No Yes Segmentation fault (gdb) c Continuing. warning: Couldn't get registers. warning: Couldn't get registers. warning: Couldn't get registers. ptrace: Operation not permitted. warning: Couldn't get registers. warning: Couldn't get registers. warning: Couldn't get registers. Cannot remove breakpoints because program is no longer writable. It might be running in another process. Further execution is probably impossible. 0x100b2f64 in sigprocmask () at eth_kern.c:307 307 } (gdb) -- "We are all so much together and yet we are all dying of loneliness."--A.Schweitzer |
|
From: Robert R. <ip...@di...> - 2000-10-11 12:46:56
|
I really have no idea what I'm doing.
180000e
att 1
b start_kernel
c
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and yo
welcome to change it and/or distribute copies of it under certain condi
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for deta
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) att 1
Attaching to program: /home/rendler/uml/linux, Pid 1
0x100b2fe1 in kill () at eth_kern.c:307
307 eth_kern.c: No such file or directory.
(gdb) b start_kernel
Breakpoint 1 at 0x100f37b9: file init/main.c, line 515.
(gdb) c
Continuing.
Breakpoint 1, start_kernel () at init/main.c:515
515 printk("Kernel command line: %s\n", saved_command_line)
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x10038490 in padzero (elf_bss=1073818712)
at /usr/src/linux/include/asm/arch/string.h:418
418 /usr/src/linux/include/asm/arch/string.h: No such file or direc
(gdb) handle SIGSEGV pass nostop noprint
Signal Stop Print Pass to program Description
SIGSEGV No No Yes Segmentation fault
(gdb) c
Continuing.
Program received signal SIGINT, Interrupt.
0x10007040 in panic (fmt=0x10120a80 "Stack overflowed onto current_task
at panic.c:100
100 for(;;) {
(gdb)
--
"We are all so much together and yet we are all dying of loneliness."--A.Schweitzer
|
|
From: Jeff D. <jd...@ka...> - 2000-10-11 16:56:31
|
> Program received signal SIGINT, Interrupt.
> 0x10007040 in panic (fmt=0x10120a80 "Stack overflowed onto current_task
> at panic.c:100
> 100 for(;;) {
> (gdb)
That looks better. Did you do anything different that time?
At this point, you supposed to do a 'bt' to see what's going on, and then
'return' you way up the stack, looking at $esp at each frame see see who's
eating up the stack.
> (gdb) att 1
> Attaching to program: /home/rendler/uml/linux, Pid 1
> 0x100b2fe1 in kill () at eth_kern.c:307
> 307 eth_kern.c: No such file or directory.
This still makes me a bit nervous. I'm not sure where it's supposed to be when
it gets attached, but I don't think it's the ethernet driver.
Jeff
|
|
From: Robert R. <ip...@di...> - 2000-10-12 01:16:27
Attachments:
bleh
|
|
From: Jeremy F. <je...@go...> - 2000-10-08 08:40:13
|
On Sun, Oct 08, 2000 at 12:35:48AM -0500, Jeff Dike wrote: > I've been waiting for someone to send me that stack. There aren't any real > smoking guns there. I'm guessing that the difference between your laptop and > the machine it works on is that your laptop is running a fairly recent kernel > (2.4.0-testx) and the other isn't. Yep, that's right. > The sigcontext struct greatly increased in > size (to ~800 bytes IIRC) to accomodate the MMX registers or something. There > are three signals on your stack, so those frames by themselves are taking up > half the stack page. > > Anyway, the patch below removes 256 bytes from the set_signals frame. It > ought to alleviate things a bit. I'll be looking for other things I can do, > as well. Let me know how it works for you. I'm afraid this doesn't help. The stack still overflows at the same point. It looks like each signal frame is ~760 bytes. Even with this patch, the overflow is 808 bytes (without the patch it's 1232 bytes). J |
|
From: David C. <tec...@li...> - 2000-10-10 20:39:13
|
On Sun, 8 Oct 2000, Jeff Dike wrote: > Anyway, the patch below removes 256 bytes from the set_signals frame. It > ought to alleviate things a bit. I'll be looking for other things I can do, > as well. Let me know how it works for you. I tried to apply that patch to a checkout of the uml code from cvs, and it failed. Either it has been applied (doesn't look like it) to the code which is in cvs already, or I'm doing something stupid. Ideas? -- David Coulson tec...@so... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X