[sdcc-devel] [ sdcc-Bugs-3502626 ] gcc-torture-execute-20030209-1 segfaults

[SourceForge.net <no...@so...>]

Bugs item #3502626, was opened at 2012-03-12 06:42
Message generated for change (Comment added) made by spth
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3502626&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: hc08 port
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Philipp Klaus Krause (spth)
Assigned to: Nobody/Anonymous (nobody)
Summary: gcc-torture-execute-20030209-1 segfaults

Initial Comment:
The regression test gcc-torture-execute-20030209-1 segfaults for hc08. To reproduce, remove the #ifdef.

Philipp


----------------------------------------------------------------------

>Comment By: Philipp Klaus Krause (spth)
Date: 2012-03-16 03:08

Message:
It looks better now, I just get

internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C6C
internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C6C
internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C70
internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C70
internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C75
internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C75
internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C79
internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C79
internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C80
internal memory limit is exceeded for XSEG; memory size = 0x010000, address
= 0x011C80

and no segfault any more.

Philipp


----------------------------------------------------------------------

Comment By: Erik Petrich (epetrich)
Date: 2012-03-16 02:21

Message:
Based on the messages you reported, I fixed a likely suspect for the
segfault in revision #7455, but I don't know for sure because I still
haven't been able to reproduce it (the closest system to yours that I have
is x86-64 Fedora 12 GNU/Linux). Please try it out.

There was a problem with bound checking on the allocation bitmap. The code
was incorrectly using the byte size of the array when it should have been
using the number of elements in the array. There are several large bitmaps
at the global scope, so I suspect that depending on how they are ordered in
memory (which might change with compiler/linker version) one could either
get a segfault or silent corruption of another bitmap.

----------------------------------------------------------------------

Comment By: Philipp Klaus Krause (spth)
Date: 2012-03-15 05:05

Message:
I can reproduce the segfault on both system I use (x86-64, Debian
GNU/Linux, one running Debian testing, the other running Debian unstable).
I gdb it look slike this:

[…]
memory overlap near 0x38993 for XSEG
memory overlap near 0x389B3 for XSEG
memory overlap near 0x389D3 for XSEG
memory overlap near 0x389F3 for XSEG
memory overlap near 0x38A33 for XSEG
memory overlap near 0x38A53 for XSEG
memory overlap near 0x38A73 for XSEG
memory overlap near 0x38AB3 for XSEG
memory overlap near 0x38AD3 for XSEG
memory overlap near 0x38AF3 for XSEG
Segmentation fault
[Inferior 1 (process 27105) exited with code 01]
(gdb) bt
No stack.

Philipp


----------------------------------------------------------------------

Comment By: Philipp Klaus Krause (spth)
Date: 2012-03-15 04:30

Message:
How about making the array size depend on the port? AFAIK, it is that way
with som eother tests, too. We then would make the array smaller for hc08
and gbz80.

Philipp


----------------------------------------------------------------------

Comment By: Erik Petrich (epetrich)
Date: 2012-03-14 22:43

Message:
I can't reproduce the segfault.


----------------------------------------------------------------------

Comment By: Erik Petrich (epetrich)
Date: 2012-03-14 15:09

Message:
While the segfault is still a problem, this test would still fail for the
hc08 as-is. The default linker options for the hc08 (and left unchanged by
the regression test environment) locate the program in the upper 32k,
leaving the lower 32k for variables and stack. The "double x[100][100]"
declaration needs 40k.

Is the array size relevant to the problem this test is checking? If not, I
think it would be better to use a smaller array than to completely disable
the test.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3502626&group_id=599