#1965 gcc-torture-execute-20030209-1 segfaults

closed-fixed
hc08 port (43)
5
2012-09-16
2012-03-12
No

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

Philipp

Discussion

  • Erik Petrich

    Erik Petrich - 2012-03-14

    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.

     
  • Erik Petrich

    Erik Petrich - 2012-03-15

    I can't reproduce the segfault.

     
  • Philipp Klaus Krause

    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

     
  • Philipp Klaus Krause

    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

     
  • Erik Petrich

    Erik Petrich - 2012-03-16

    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.

     
  • Philipp Klaus Krause

    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

     
  • Maarten Brock

    Maarten Brock - 2012-05-12

    Does anyone have clue what the purpose of this test is? Was it to test offsets > 64k ?
    This seems to be problem with all 'dated' gcc regression tests, that it is unclear what they should test.

    And this test only passes because double is implemented as float by SDCC. Otherwise it would fail for any target except ds390. All the others have address spaces <=64k if I'm not mistaken.

    I would like to suggest to remove this test completely. There is nothing 'Small' (as in SDCC) about it.

     
  • Philipp Klaus Krause

    Yes, it is annoying not to know what the tests orifinally were meant for. Neverheless they have helped find is quite some bugs - even this one. I suppose this test is meant for some optimization technique that failed due to the big two-dimensional array - maybe a dead code elimination failure wrongly assuming that x[i][0] = 42 is dead or cse wrongly optimizing x[99][0] != 42 into true.
    I thus suggest to not remove this test and instead reduce the array size in both dimensions.

    Philipp

     
  • Philipp Klaus Krause

    • assigned_to: nobody --> spth
    • status: open --> closed-fixed
     
  • Philipp Klaus Krause

    epetrich has fixed the segafult some time ago.
    I have changed the array size so this test is viable for our targets in revision #8107, and thus close this bug as fixed.

    Philipp

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks