[Bug go/64001] gccgo: crash on stack splitting

2016-02-10 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-02-10
 Ever confirmed|0   |1

[Bug go/64001] gccgo: crash on stack splitting

2015-02-02 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001

--- Comment #7 from Ian Lance Taylor ian at airs dot com ---
Sorry, I missed that this only happens with 4.9.  Unfortunately, I was also
unable to reproduce it with 4.9.

I have no idea what the problem is.  If you can still reproduce it, run it
under strace to see what values mmap returns and make sure it returns normal
values.

Otherwise, the only thing I can think of is that somehow memory is being
corrupted.  That could be due to changes in the garbage collector.  I haven't
seen any other reports that suggest this, though.


[Bug go/64001] gccgo: crash on stack splitting

2015-02-01 Thread michael.hudson at canonical dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001

--- Comment #6 from Michael Hudson-Doyle michael.hudson at canonical dot com 
---
Which version were you using?  I've never been able to reproduce it with
anything newer than the 4.9 series.  I'd love to know what the fix was so we
can investigate backporting it...


[Bug go/64001] gccgo: crash on stack splitting

2015-01-30 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001

--- Comment #5 from Ian Lance Taylor ian at airs dot com ---
Just a note that I have not been able to reproduce this.  I ran the program
from comment #1 50 times with no failures.


[Bug go/64001] gccgo: crash on stack splitting

2014-12-03 Thread michael.hudson at canonical dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001

--- Comment #4 from Michael Hudson-Doyle michael.hudson at canonical dot com 
---
Well, it seems to report that __morestack_segments 
__morestack_current_segment are always NULL for all threads.  I don't
understand the morestack code perfectly, but this seems a bit unlikely to
actually be the case.

GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs seems like it should be new
enough?


[Bug go/64001] gccgo: crash on stack splitting

2014-12-02 Thread michael.hudson at canonical dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001

--- Comment #1 from Michael Hudson-Doyle michael.hudson at canonical dot com 
---
Created attachment 34175
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34175action=edit
very small reproducer

Well, here is a very small reproducer indeed.  gccgo-go run boom.go fails ~50%
of the time.  Maybe it really is something to do with the https parsing code...


[Bug go/64001] gccgo: crash on stack splitting

2014-12-02 Thread michael.hudson at canonical dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001

--- Comment #2 from Michael Hudson-Doyle michael.hudson at canonical dot com 
---
Oh, I was wrong in my initial comment.  Setting a breakpoint like this:

(gdb) br *0x7971
Breakpoint 5 at 0x7971: file
../../../src/libgcc/config/i386/morestack.S, line 512.
(gdb) commands
Type commands for breakpoint(s) 5, one per line.
End with a line saying just end.
silent
print $rax
continue
end
(gdb) c

(0x7971 is the instruction after the __generic_morestack call)
results (eventually) in output like this:

...
$202479 = 140737354018816
$202480 = 140737354022912
$202481 = 281474706301792

Program received signal SIGBUS, Bus error.
__morestack () at ../../../src/libgcc/config/i386/morestack.S:529
529../../../src/libgcc/config/i386/morestack.S: No such file or directory.
(gdb) p/x 281474706301792
$202482 = 0xefe1e360

So it does seem that __generic_morestack is returning junk.  I can't figure out
how to get gdb to show me the values of the __thread variables this is using
though, so I don't know _why_ it's returning junk.


[Bug go/64001] gccgo: crash on stack splitting

2014-12-02 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001

--- Comment #3 from Ian Lance Taylor ian at airs dot com ---
On GNU/Linux gdb can usually print TLS variables fine.  It knows how to look up
the value for the current thread.  Make sure you are using a sufficiently new
version of gdb, although I think it's been supported for a few years now.