Adam Waltman wrote:
> Could anything be done to help me not to rebooot the server every time?
This really makes no sense to me. I heard you mention it before but I
ignored it then. Why do you have to reboot your machine even once?
User space processes should not be able to crash the kernel.
Sin
Quoting Philip Rowlands <[EMAIL PROTECTED]>:
$ gdb -x <( printf "run\nbt" ) --args ./segv
Program received signal SIGSEGV, Segmentation fault.
0x0804836e in ?? ()
#0 0x0804836e in ?? ()
#1 0xb7fc0020 in __libc_missing_32bit_uids () from /lib/ld-linux.so.2
#2 0x080483c8 in ?? ()
#3 0xbf8bebe8
Quoting Philip Rowlands <[EMAIL PROTECTED]>:
This is still putting your whole system in doubt, I'm afraid. gdb and
shred aren't magic unkillable processes; there's no reason they should
be hanging on the second invocation. If there's a process unkillable in
state "D", try this to see where it's
[gdb displays nothing]
Or a sign that everything was configured with debug information
stripped and compilation took place with optimizations
Not on my machine...
$ cat segv.c
#include
void main() {
memcpy(0, "hello", 5);
}
$ gcc -O3 -o segv segv.c
segv.c: In function `main':
segv.c:2: warnin
On 4/19/06, Adam Waltman <[EMAIL PROTECTED]> wrote:
> This is the error message I have in kernel log, not very helpful :-):
> Apr 18 14:05:29 [kernel] Unable to handle kernel NULL pointer dereference at
> virtual address 0018
That is a separate problem I think. A user-space program should be
Hi everyone,
I am positively suprised by the number of suggestions I have received,
thank you very much :-)!
Here is my combined response.
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> The program no longer exists.
>>> No stack.
>>> (gdb)
>>
>> Oh. That's unexpected.
>
> Or
I've long been suspicious of the 'alloca' inside shred.c. Can you
please apply the patch at the end of this message? (Save this email
into a file FOO, and then type "patch shred.c
* src/shred.c (fillrand): The assertion was way too weak, due to
what must be a typo. Strengthen i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Philip Rowlands on 4/18/2006 8:46 PM:
>
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> The program no longer exists.
>> No stack.
>> (gdb)
>
> Oh. That's unexpected.
Or a sign that everything was configured with debug
Philip Rowlands wrote:
> I tried it like this:
>
> gdb -x <( printf "run\nbt" ) --args bash -c 'kill -6 $$'
I think it is an incredibly clever way to wrap up a gdb session in
into a command line one-liner. I really like it!
Bob
___
Bug-coreutils mai
On Mon, 17 Apr 2006, Bob Proulx wrote:
Good suggestion. But I think that needs another \n in the printf.
Doesn't it?
gdb -x <( printf "run\nbt\nq\n" ) --args src/shred --remove --zero adam adam1
It's certainly cleaner, but gdb on my system seems to cope without. I
tried it like this:
gdb
Philip Rowlands wrote:
> Adam Waltman wrote:
> >k13 coreutils-5.94 # src/shred --remove --zero adam adam1
> >Segmentation fault
> >
> >It seems that he shred itself is the culprit.
> >I have no real experience in programming in Linux,
> >but I have installed gdb and tried to squeeze something out o
[EMAIL PROTECTED] (Bob Proulx) writes:
> make[3]: Entering directory `.../tests/shred'
> ...
> ./exact: line 25: 23017 Segmentation fault shred --remove $opt a b
> ./exact: line 25: 23018 Segmentation fault shred --remove $opt c
> FAIL: exact
These are strange messages, since
Thanks for the bug report. Please keep bug-coreutils in the CC line
so that others may participate in the discussion.
Adam Waltman wrote:
> I am trying to install coreutils-5.94 on my Gentoo system.
> It fails during test stage. I have entered the error report here:
> http://forums.gentoo.o
13 matches
Mail list logo
