Bug#67099: segfault on m68k
Chris Lawrence
> Well, reportbug segfaults on m68k, therefore this bug report is written on
> i386... ;-))
>
> Just installed reportbug with apt-get install reportbug and got:
>
> ij@arrakis:~$ reportbug -S wishlist hwtools
> Segmentation fault
>
>
> When trying as root, result is:
>
> arrakis:~# reportbug -S wishlist hwtools
> Running 'reportbug' as root is probably insecure!
> Continue [y|N|?]? n
> Segmentation fault
I can't duplicate this on kullervo (m68k.debian.org) with the source
package. Can anyone else duplicate this?
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bjoern Brill
On Wed, 12 Jul 2000, Chris Lawrence wrote:
> On Jul 12, Ingo Juergensmann wrote:
> > Well, reportbug segfaults on m68k, therefore this bug report is written on
> > i386... ;-))
> >
> > Just installed reportbug with apt-get install reportbug and got:
> >
> > ij@arrakis:~$ reportbug -S wishlist hwtools
> > Segmentation fault
> >
> >
> > When trying as root, result is:
> >
> > arrakis:~# reportbug -S wishlist hwtools
> > Running 'reportbug' as root is probably insecure!
> > Continue [y|N|?]? n
> > Segmentation fault
>
> I can't duplicate this on kullervo (m68k.debian.org) with the source
> package. Can anyone else duplicate this?
>
I can [the following pseudo-report has been generated with bug].
---------------8<---------------------------8<------------------------
Subject: reportbug: segfaults for me, too.
Package: reportbug
Version: 0.54
Severity: normal
I can confirm this. See captured session below. System is a Macintosh,
Quadra 700.
Script started on Thu Jul 13 18:34:27 2000
brill@inkling:~$ reportbug -b -o reportbug.txt
Please enter the name of the package in which you have found a problem,
or type one of these bug categories:
Segmentation fault
brill@inkling:~$ reportbug
Please enter the name of the package in which you have found a problem,
or type one of these bug categories:
Segmentation fault
brill@inkling:~$ exit
exit
Script done on Thu Jul 13 18:35:23 2000
-- System Information
Debian Release: 2.2
Kernel Version: Linux inkling 2.2.14 #1 Mon Apr 24 01:25:13 CEST 2000 m68k unknown
Versions of the packages reportbug depends on:
ii python-base 1.5.2-10 An interactive object-oriented scripting lan
ii python-newt 0.50-7 A newt module for Python.
ii whiptail 0.50-7 Displays user-friendly dialog boxes from she
---------------8<---------------------------8<------------------------
If you want an strace or similar, please tell me.
Regards,
Björn Brill
--
Bj"orn Brill <br...@fs.math.uni-frankfurt.de>
Frankfurt am Main, Germany
Chris Lawrence
> I can [the following pseudo-report has been generated with bug].
>
> ---------------8<---------------------------8<------------------------
> Subject: reportbug: segfaults for me, too.
>
> Package: reportbug
> Version: 0.54
> Severity: normal
>
> I can confirm this. See captured session below. System is a Macintosh,
> Quadra 700.
Hmm, I suspect readline. See if this script segfaults:
---
#!/usr/bin/python
import readline
print raw_input("Enter something here: ")
---
Then try it without the "import readline". If this segfaults, it's a
bug in python-base (probably a misdeclared dependency).
If it's not that, I'll have to put some additional debugging code in
to diagnose it.
Chris
--
=============================================================================
| Chris Lawrence | Get rid of Roger Wicker this year! |
| <qua...@watervalley.net> | http://www.lordsutch.com/ms-one/ |
| | |
| Grad Student, Pol. Sci. | Join the party that opposed the CDA |
| University of Mississippi | http://www.lp.org/ |
=============================================================================
Ingo Juergensmann
> > I can confirm this. See captured session below. System is a Macintosh,
> > Quadra 700.
> Hmm, I suspect readline. See if this script segfaults:
> ---
> #!/usr/bin/python
> import readline
> print raw_input("Enter something here: ")
> ---
> Then try it without the "import readline". If this segfaults, it's a
> bug in python-base (probably a misdeclared dependency).
> If it's not that, I'll have to put some additional debugging code in
> to diagnose it.
This script works fine here, both with and without "import readline".
Maybe I could strace my reportbug... tell me, if it's ok to post this output
to bugs....
Ciao...
Ingo
Christian T. Steigies
> If it's not that, I'll have to put some additional debugging code in
> to diagnose it.
Christian
Package: reportbug
Version: 0.54
Severity: normal
unfortunately, this package seems to work fine on my amiga...
-- System Information
Debian Release: 2.2
Architecture: m68k
Kernel: Linux aahz 2.2.10 #1 Sun Apr 9 10:14:31 CEST 2000 m68k
Versions of packages reportbug depends on:
ii python-base 1.5.2-10 An interactive object-oriented scr
ii python-newt 0.50-7 A newt module for Python.
ii whiptail 0.50-7 Displays user-friendly dialog boxe
Ingo Juergensmann
> > If it's not that, I'll have to put some additional debugging code in
> > to diagnose it.
> works fine here out of the box.
> Version: 0.54
> unfortunately, this package seems to work fine on my amiga...
Here it segfaults out of the box. So why does it work on yours and not on
mine and why does it not work on that other m68k Apple?
> -- System Information
> Debian Release: 2.2
> Architecture: m68k
> Kernel: Linux aahz 2.2.10 #1 Sun Apr 9 10:14:31 CEST 2000 m68k
arrakis:/usr/local/test-rc5/clientpub# uname -a
Linux arrakis 2.2.10 #1 Sun Apr 9 10:14:31 CEST 2000 m68k unknown
... standard kernel...
> Versions of packages reportbug depends on:
> ii python-base 1.5.2-10 An interactive object-oriented scr
> ii python-newt 0.50-7 A newt module for Python.
> ii whiptail 0.50-7 Displays user-friendly dialog boxe
Same versions here.
A strace output is available at
http://www.cologne.de/~spice/strace-output.txt
Ciao...
Ingo
Christian T. Steigies
> > Architecture: m68k
> > Kernel: Linux aahz 2.2.10 #1 Sun Apr 9 10:14:31 CEST 2000 m68k
>
> arrakis:/usr/local/test-rc5/clientpub# uname -a
> Linux arrakis 2.2.10 #1 Sun Apr 9 10:14:31 CEST 2000 m68k unknown
>
> ... standard kernel...
> > Versions of packages reportbug depends on:
> > ii python-base 1.5.2-10 An interactive object-oriented scr
> > ii python-newt 0.50-7 A newt module for Python.
> > ii whiptail 0.50-7 Displays user-friendly dialog boxe
>
> Same versions here.
>
> A strace output is available at
> http://www.cologne.de/~spice/strace-output.txt
You are running it as root? It tells you not to do so... maybe its a
security enforcement by Chris? Try to run it from a user account, please.
Christian
Ingo Juergensmann
> > A strace output is available at
> > http://www.cologne.de/~spice/strace-output.txt
> You are running it as root? It tells you not to do so... maybe its a
> security enforcement by Chris? Try to run it from a user account, please.
As I wrote in my first bug report it segfaults as a normal user, too. The
only difference is that reportbug advices you that it may be insecure to run
as root, but it segfaults both no matter if run by root or by user.
http://www.cologne.de/~spice/user-strace-output.txt
Ciao...
Ingo
Bjoern Brill
On Thu, 13 Jul 2000, Chris Lawrence wrote:
> On Jul 13, Bjoern Brill wrote:
[...]
> > I can confirm this. See captured session below. System is a Macintosh,
> > Quadra 700.
>
> Hmm, I suspect readline. See if this script segfaults:
>
> ---
> #!/usr/bin/python
> import readline
>
> print raw_input("Enter something here: ")
> ---
>
> Then try it without the "import readline". If this segfaults, it's a
> bug in python-base (probably a misdeclared dependency).
>
segfaults neither with nor without "import readline" on this box.
I noticed something different, but strange: stracing reportbug several
times, I invariably got (much stuff, only last few lines shown):
stat("/etc/reportbug.conf", {st_mode=S_IFREG|0644, st_size=1997, ...}) = 0
open("/etc/reportbug.conf", O_RDONLY) = 4
read(4, "#", 1) = 1
fstat(4, {st_mode=S_IFREG|0644, st_size=1997, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc0014000
read(4, " Example configuration file for "..., 4096) = 1996
read(4, "", 4096) = 0
stat("/home/fsmath/brill/.reportbugrc", 0xeffff794) = -1 ENOENT (No such file or directory)
close(4) = 0
munmap(0xc0014000, 4096) = 0
getuid() = 502
pipe([4, 5]) = 0
fork() = 15818
close(5) = 0
fstat(4, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
lseek(4, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fstat(4, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc0014000
read(4, "/dev/tty1\n", 4096) = 10
read(4, "", 4096) = 0
--- SIGCHLD (Child exited) ---
close(4) = 0
wait4(15818, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 15818
munmap(0xc0014000, 4096) = 0
write(2, "Please enter the name of the pac"..., 110Please enter the name of the package in which you have found a problem,
or type one of these bug categories:
) = 110
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
looking at the strace, I saw reportbug wants to read ~/.reportbugrc
and I don't have one, so I created an empty one and now reportbug
invariably segfaults AT A DIFFERENT PLACE:
--- SIGCHLD (Child exited) ---
close(4) = 0
wait4(15847, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 15847
munmap(0xc0014000, 4096) = 0
stat("/etc/reportbug.conf", {st_mode=S_IFREG|0644, st_size=1997, ...}) = 0
open("/etc/reportbug.conf", O_RDONLY) = 4
read(4, "#", 1) = 1
fstat(4, {st_mode=S_IFREG|0644, st_size=1997, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc0014000
read(4, " Example configuration file for "..., 4096) = 1996
read(4, "", 4096) = 0
stat("/home/fsmath/brill/.reportbugrc", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("/home/fsmath/brill/.reportbugrc", O_RDONLY) = 5
close(4) = 0
munmap(0xc0014000, 4096) = 0
read(5, "", 1) = 0
close(5) = 0
getuid() = 502
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
I suspect the following reason: on this m68k box, most programs linked
against libpthread.so segfault without visible reason, usually a short
time after fork()ing (for example, nscd silently dies because of this, as
does ypbind). Now /usr/bin/python IS linked against libpthread and we have
definitely fork()ed since we get a SIGCHLD.
Björn
--
Bj"orn Brill <br...@fs.math.uni-frankfurt.de>
Frankfurt am Main, Germany
--
Chris Lawrence
> I suspect the following reason: on this m68k box, most programs linked
> against libpthread.so segfault without visible reason, usually a short
> time after fork()ing (for example, nscd silently dies because of this, as
> does ypbind). Now /usr/bin/python IS linked against libpthread and we have
> definitely fork()ed since we get a SIGCHLD.
Hmm, perhaps Python on m68k shouldn't be linked against pthread, at
least on potato. I guess the longterm solution is for someone to look
at what's wrong with (I assume) the handcoded assembly in
libpthread. But there isn't that much there...
OTOH it could be nastiness with cas (compare and set) and its buddies
on certain systems, in which case it's a hardware limitation. Maybe
disabling compare_and_set() in libpthread might help, though I dunno.
In any case, I know it works on 2 68060 Amiga systems (kullervo and
CTS's); maybe we can narrow it down to a particular 0x0 and/or
hardware platform (Mac, Amiga, Atari) and go from there.
Chris
Bjoern Brill
> On Jul 14, Bjoern Brill wrote:
> > I suspect the following reason: on this m68k box, most programs linked
> > against libpthread.so segfault without visible reason, usually a short
> > time after fork()ing (for example, nscd silently dies because of this, as
> > does ypbind). Now /usr/bin/python IS linked against libpthread and we have
> > definitely fork()ed since we get a SIGCHLD.
>
> Hmm, perhaps Python on m68k shouldn't be linked against pthread, at
> least on potato. I guess the longterm solution is for someone to look
> at what's wrong with (I assume) the handcoded assembly in
> libpthread. But there isn't that much there...
>
> OTOH it could be nastiness with cas (compare and set) and its buddies
> on certain systems, in which case it's a hardware limitation. Maybe
> disabling compare_and_set() in libpthread might help, though I dunno.
>
> In any case, I know it works on 2 68060 Amiga systems (kullervo and
> CTS's); maybe we can narrow it down to a particular 0x0 and/or
> hardware platform (Mac, Amiga, Atari) and go from there.
>
OK.
Amiga, 68040: segfaults (Ingo Juergensmann, original bug report)
Amiga, 68060: works (kullervo)
Amiga, 68060: works (CTS)
Mac, 68040: segfaults (Björn Brill)
Anyone else?
Björn
--
Bj"orn Brill <br...@fs.math.uni-frankfurt.de>
Frankfurt am Main, Germany
Michael Schmitz
> Amiga, 68040: segfaults (Ingo Juergensmann, original bug report)
> Amiga, 68060: works (kullervo)
> Amiga, 68060: works (CTS)
> Mac, 68040: segfaults (Björn Brill)
Anyone tried on a 030 yet? I'd suspect it's the 040; if the 030 also dies
someone might have used a 060 only instruction. I doubt it's cas, I don't
think the Mac has a problem with that (at least no one noticed so far),
and on Amiga it should be a problem only on some sort of memory that
shouldn't be used by Linux anyway.
Michael
Chris Baker
> >
> > Amiga, 68040: segfaults (Ingo Juergensmann, original bug report)
> > Amiga, 68060: works (kullervo)
> > Amiga, 68060: works (CTS)
> > Mac, 68040: segfaults (Björn Brill)
>
> Anyone tried on a 030 yet? I'd suspect it's the 040; if the 030 also dies
> someone might have used a 060 only instruction. I doubt it's cas, I don't
> think the Mac has a problem with that (at least no one noticed so far),
> and on Amiga it should be a problem only on some sort of memory that
> shouldn't be used by Linux anyway.
Works fine on my IIci (an '030).
Cheers,
cbb
Michael Schmitz
> > > Mac, 68040: segfaults (Björn Brill)
> >
> > Anyone tried on a 030 yet? I'd suspect it's the 040; if the 030 also dies
> > someone might have used a 060 only instruction. I doubt it's cas, I don't
> > think the Mac has a problem with that (at least no one noticed so far),
> > and on Amiga it should be a problem only on some sort of memory that
> > shouldn't be used by Linux anyway.
>
> Works fine on my IIci (an '030).
OK; that strongly hints at a specific 040 problem. Can the fault address
be correlated with some code fragment? Or can the problematic code be
compiled using just 030 instructions?
Michael
Richard Zidlicky
> > > > Amiga, 68060: works (CTS)
> > > > Mac, 68040: segfaults (Björn Brill)
> > >
> > > Anyone tried on a 030 yet? I'd suspect it's the 040; if the 030 also dies
> > > someone might have used a 060 only instruction. I doubt it's cas, I don't
> > > think the Mac has a problem with that (at least no one noticed so far),
> > > and on Amiga it should be a problem only on some sort of memory that
> > > shouldn't be used by Linux anyway.
> >
> > Works fine on my IIci (an '030).
>
> OK; that strongly hints at a specific 040 problem. Can the fault address
> be correlated with some code fragment? Or can the problematic code be
> compiled using just 030 instructions?
found the problem, the 040 buserror handler is guilty. Patch is beeing tested
right now.
Bye
Richard
Bjoern Brill
On Tue, 22 Aug 2000, Richard Zidlicky wrote:
> found the problem, the 040 buserror handler is guilty. Patch is beeing tested
> right now.
>
What was the result of the tests? Is the patch available somewhere?
Against which kernel?
It seems this has been discussed on the linux-m68k list, but I'm not
subscribed to it and couldn't find a working archive either.
Thanks,
Bjoern Brill
--
Bj"orn Brill <br...@fs.math.uni-frankfurt.de>
Frankfurt am Main, Germany