https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #19 from Eric Botcazou ---
> if I use kill -11, I would be really surprised to see
> the process freeze.
>
> It would be good to look at siginfo->si_code
> and _not_ continue the normal exception handling
> when the si_code is SI_USE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #18 from Bernd Edlinger ---
Hi Eric,
if I use kill -11, I would be really surprised to see
the process freeze.
It would be good to look at siginfo->si_code
and _not_ continue the normal exception handling
when the si_code is SI_USER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #17 from Bernd Edlinger ---
Oh, I see: I forgot to add -fstack-check.
After re-compiling with -fstack-check the modified test case passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #16 from Eric Botcazou ---
> you could avoid that scenario by probing say 4K of stack in __gnat_malloc ?
No, the stack checking model is to probe sufficiently ahead in the user code by
means of -fstack-check but not in the run time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #15 from Bernd Edlinger ---
you could avoid that scenario by probing say 4K of stack in __gnat_malloc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #14 from Bernd Edlinger ---
hmm, ok, but how about this:
--- ../gcc-trunk/gcc/testsuite/ada/acats/tests/cb/cb1010d.ada2014-05-24
19:26:45.338568486 +0200
+++ cb1010d.adb2015-01-04 12:55:21.458653242 +0100
@@ -29,14 +29,23 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Bernd Edlinger changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #11 from Bernd Edlinger ---
Sorry.
again the test case c380004
just with this little addition
begin
Test ("C380004",
"Check evaluation of discriminant expressions " &
"when the constraint depends on a disc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #10 from Andrew Pinski ---
(In reply to Bernd Edlinger from comment #9)
> I still dont see what's wrong with tsan here, the signal could
> easily be from a kill -SIGSEGV .
Because this is while executing in the synchonous signal form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #9 from Bernd Edlinger ---
Sorry, Andrew,
a deadlock in the Ada exception handler is an Ada BUG
by definition.
Even if YOU can't fix it easily.
The memory could be pre-allocated as the call stack
and we should make it to the point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Bernd Edlinger changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #6 from Andrew Pinski ---
(In reply to Bernd Edlinger from comment #5)
> but I cant see why a potential deadlock in an exception
> handler is not a bug?
Actually here is what glibc says about malloc:
Function: void * malloc (size_t s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #5 from Bernd Edlinger ---
but I cant see why a potential deadlock in an exception
handler is not a bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Bernd Edlinger changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #1 from Bernd Edlinger ---
I found this initially with TSAN:
RUN c52104x
^M
,.,. C52104X ACATS 2.5 15-01-03 04:12:21^M
C52104X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,^M
THE LENGTHS MUST MATCH; A
19 matches
Mail list logo
