Control: tag 743141 wontfix
On 20/05/14 13:45, Debian Bug Tracking System wrote:
retitle 743141 kfreebsd-9: triple fault on execve from 64-bit thread to 32-bit
process
Tentatively tagging 743141 wontfix as kfreebsd-9 is planned for removal.
But, AFAIK, it can't be removed yet as latest D-I
Robert Millan r...@debian.org (2014-05-22):
Control: tag 743141 wontfix
On 20/05/14 13:45, Debian Bug Tracking System wrote:
retitle 743141 kfreebsd-9: triple fault on execve from 64-bit thread to
32-bit process
Tentatively tagging 743141 wontfix as kfreebsd-9 is planned for removal.
tags 743141 + fixed-upstream
thanks
Fix committed to head:
http://svnweb.freebsd.org/base?view=revisionsortby=daterevision=266464
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Hi,
On 10/05/14 15:52, Christoph Egger wrote:
Steven Chamberlain ste...@pyro.eu.org writes:
Everything can be deleted from
~/gcc-4.7-4.7.3/src/gcc/testsuite/gcc.c-torture/compile/ except for
pr44686.c, which necessitates building tls_runtime, which triggers the
bug immediately.
Did you
Hi.
Did you manage to figure something additional out? Do we know if this
also kills plain freebsd?
I'm afraid I'm stuck with this.
I narrowed it down to that particular test (or prerequisites of the
test) when executed by the GCC testsuite. A large chroot is needed,
having all the GCC
On 11/05/14 18:18, Petr Salinger wrote:
I tried under plain FreeBSD kernel (via kfreebsd-downloader-10)
and it does not reboot for me.
It still crashes reproducibly for me, on upstream's build of:
GNU/kFreeBSD debian 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
Jan 16 22:34:59 UTC 2014
Finally getting somewhere!
testcase.c can be just:
int main() { }
Use the system GCC, don't need to compile it from source.
$ gcc -o testcase testcase.c
This is on kfreebsd-amd64, the executable is 64-bit.
Use expect to spawn it like this (same way that dejagnu does in the GCC
testsuite) :
Attached is a ktrace of expect spawning a 64-bit executable.
I can't do this for the 32-bit testcase because the system crashes
before any ktrace output is written to disk. Ivo's screenshot
implicated a 'spin lock held too long'.
I tried replacing the testcase with something that does sleep(10)
An even simpler way, don't need the expect program. Create a thread in
a 64-bit process, and try to execve() a 32-bit executable:
#include unistd.h
#include pthread.h
void *thread_main() {
char *cmdline[] = { ./testcase32, NULL };
execve(cmdline[0], cmdline, NULL);
}
Hi!
Steven Chamberlain ste...@pyro.eu.org writes:
Everything can be deleted from
~/gcc-4.7-4.7.3/src/gcc/testsuite/gcc.c-torture/compile/ except for
pr44686.c, which necessitates building tls_runtime, which triggers the
bug immediately.
The tls_runtime exe survives a reboot if building on
To reproduce this, the unix/-m32 test suite can be invoked with:
$ cd ~/gcc-4.7-4.7.3/src/gcc/testsuite
$ make check RUNTESTFLAGS='--target_board unix/-m32 -v -v'
First, many compiler regression tests are run successfully.
Later, some helper executable tls_runtime2029.exe is built. I think the
Everything can be deleted from
~/gcc-4.7-4.7.3/src/gcc/testsuite/gcc.c-torture/compile/ except for
pr44686.c, which necessitates building tls_runtime, which triggers the
bug immediately.
The tls_runtime exe survives a reboot if building on ufs mounted with -o
sync. But executing it manually (in
On 25/04/14 18:38, Petr Salinger wrote:
I tested it:
system up-to-date jessie, with kfreebsd-image-10.0-1-amd64/10.0-4
Same here. I used a plain ufs filesystem and no swap.
It seems to be during test of gcc unix/-m32.
Yes. I reproduced this with kernel messages going to a serial console
Do you have any news on this bug? It is severely affecting *all* GCC
versions and prevents new versions of them from migrating to testing.
I tested it:
system up-to-date jessie, with kfreebsd-image-10.0-1-amd64/10.0-4
chroot up-to-date sid, building of gcc-4.6 4.6.4-6 rebooted the system.
It
Dear BSD porters,
Do you have any news on this bug? It is severely affecting *all* GCC
versions and prevents new versions of them from migrating to testing.
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
15 matches
Mail list logo