--- Comment #5 from artem at bizlink dot ru 2007-07-20 11:39 ---
> I think the best JVM-compatible action then would be
> to shutdown the failed thread,
> but let the other threads continue...
E... I wasn't really going to post this. Forgot to clear the textarea.
--- Comment #4 from artem at bizlink dot ru 2007-07-20 11:34 ---
I think the best JVM-compatible action then would be to shutdown the failed
thread, but let the other threads continue...
--
artem at bizlink dot ru changed:
What|Removed |Added
--- Comment #3 from artem at bizlink dot ru 2007-07-20 11:27 ---
To clarify:
this is a buffer overflow, catched by the GCJ SIGSEGV handler.
GCJ then tries to build a strack trace, but stack is obviously broken.
Still, it's not pretty that GCJ goes into an infinite loop via SI
--- Comment #2 from artem at bizlink dot ru 2007-07-20 10:38 ---
> In fact, I have two cores with this infinite loop,
> and they both are very large
12 mb when compressed with p7zip, so I can still deliver upon request.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
--- Comment #1 from artem at bizlink dot ru 2007-07-20 10:00 ---
In fact, I have two cores with this infinite loop, and they both are very
large:
$ l
total 304808
drwxr-xr-x 2 artemgr artemgr 4096 2007-07-20 11:58 ./
drwxr-xr-x 8 artemgr artemgr 4096 2007-07-20 11:57
java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: artem at bizlink dot ru
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
