Sorry, it's been a while. I had other things to work on on Window$ system and couldn't really check this since last week.
Anyway I tried to check the ubuntu stuff I found last time, but honestly I'm quite lost into that ubuntu patch list, (and I haven't much time to spend on this too), I've seen few things that "looks like but are not", I think what I'd really need is to forget about the diff but trying to trace into the 'signal' call to see what parameters are sent to the kernel system call by glibc, and try to figure out why it's broken. Right now I don't have time to look into this, but a quick thinking makes ask if the debug infos are provided in the slackware standard build. I'm afraid that I'll have to patch the slackbuild to do this (the easy part) and rebuild the whole stuff to have access to the source file symbols... Maybe it's the way to go, and in a sense I'd rather do that, than trying to understand a distro I'll never use :). Of course if someone is brave enough, have the time, and have the knowledge of both ubuntu and slackware builds internals, and can find a clue the diff way, you're welcome ! (Yes that's an if with a lots of 'ands'... :) ) I keep you informed if I have some fresh news. Cheers Garry |
I too haven't had time to examine this, (although I want to as these are the types of problems that fascinate me), so good luck and please do keep us posted on any findings. I will do likewise if I get the time to explore this some more.
|
I did some more googling on "segmentation fault", and found this page:
http://gcc.gnu.org/bugs/segfault.html So I tried compiling gazl-sig.c with this: Code:
gcc -Wall -O0 -g -v -da -Q -static gazl-sig.c -o sig-static Code:
gazl-sig.c.138r.jump gazl-sig.c.175r.lreg gazl-sig.c.201r.barriers |
I think that page is about debugging segmentation faults during the compilation process brian. I don't think it's going to be much help.
I've not managed to get any further with this one. How about you Garry? |
I've tried strace on both the Slack & the Ubuntu versions. Anything significant here:
Code:
execve("./sig-static", ["./sig-static"], [/* 52 vars */]) = 0 Code:
execve("./sig-static", ["./sig-static"], [/* 38 vars */]) = 0 |
I can see what looks like the bad return address being passed into rt_sigaction(), but I don't fully understand the strace syntax (what the square/curly brackets mean for example *1 ).
Slack: Code:
rt_sigaction(SIGALRM, {0x4002ac, [], SA_RESTORER, 0xf0000000fc0c748}, {SIG_DFL, [], 0}, 8) = 0 Code:
rt_sigaction(SIGALRM, {0x4002e4, [], SA_RESTORER, 0x400b80}, {SIG_DFL}, 8) = 0 edit: *1 Ahh the { } surround structs by the look of it. And it looks like "[ ]" is a representation of a NULL pointer. Cool. learnt something new. :) |
Has this difference any significance? These lines, present in the Ubuntu output, but not the Slack. It's the first thing I noticed:
Code:
open("/dev/urandom", O_RDONLY) = 3 |
Ok, I may be barking up completely the wrong tree here as I'm totally out of my depth. but I got to thinking that perhaps it's a header issue so I started poking around....
This is the definition of sigaction from slackware's /usr/include/bits/sigaction.h which is #included from /usr/include/signal.h Code:
/* Structure describing the action to be taken when a signal arrives. */ Code:
struct sigaction { Brian, can you please compare these with the header files on on ubuntu, to see whether there's a cat in my tree or not. |
Quote:
|
Right, thanks. Any more diagnostic/analytic tools I can try on the different versions?
|
GazL, you may be on to something with the difference in the headers. ubuntu patches the kernel headers because of some which are missing from a normal 'make headers_install' command -they may also be overwriting or patching the signal.h file
You might try a quick test by changing this: int sa_flags; to this: unsigned long sa_flags; in your /usr/include/bits/sigaction.h. |
That part of sigactions.h is the same in Ubuntu, but /src/linux-*/include/asm-generic/signal.h is quite different. This is it, the whole thing:
Code:
#ifndef __ASM_GENERIC_SIGNAL_H |
Ahh ok. I guess Ubuntu isn't the best of comparisons since they make so many changes to it. Thanks for putting in the effort. :)
@gnashley Thanks for that. I'm not sure it's as simple as that though. Firstly, the sa_mask member of struct sigaction appears to be in different order between those two head files (before sa_restorer in one, and after in the other). Also, if any of the signal handling routines within libc.a change those structures, and if libc.a was built using a defective header then that will probably also need rebuilding once the header has been corrected as that error will have already been compiled into the library objects. As Ubuntu isn't such a good basis for comparision, I might invest a little time and see if I can do the first few steps of a LFS install to get as clean a library/headers as I can for comparisons sake. Might take me a while though, so anyone else looking at this please feel free to do your own investigations. I'll report back if I find anything interesting. |
looks like this thing is fixed in -rc1 :)
|
Quote:
On the most recent -current: Code:
alien@slack64:~$ vi test.sh |
All times are GMT -5. The time now is 04:25 PM. |