bugText Extractor TXR - Bugs: bug #27899, Garbage collector problems on...

 
 

bug #27899: Garbage collector problems on x86-64.

Submitted by:  Kaz Kylheku <kkylheku>
Submitted on:  Sun 01 Nov 2009 07:05:56 AM UTC  
 
Category: NoneSeverity: 4 - Important
Item Group: PortabilityStatus: Fixed
Privacy: PublicAssigned to: Kaz Kylheku <kkylheku>
Originator Name: Open/Closed: Closed
Component Version: 019Operating System: None
Fixed Release: 020Planned Release: 020
Architecture: x86ABI: 64

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 03 Nov 2009 06:03:44 PM UTC, comment #3:

Closing.

Kaz Kylheku <kkylheku>
Project AdministratorIn charge of this item.
Sun 01 Nov 2009 05:17:18 PM UTC, comment #2:

Addressed with commit ad5338199ec8fe85e12dd5f3e1f94aec7ac7861b.

Kaz Kylheku <kkylheku>
Project AdministratorIn charge of this item.
Sun 01 Nov 2009 07:50:10 AM UTC, comment #1:

Specifically, the problem is with the initial bindings parsed int the main function. The makefile passes -DTESTDIR=tests/002 when invoking tests/002/query-1.txr. This -DTESTDIR=tests/002 argument turns into a bindings list which is being garbage collected away right inside main. When it's referenced later inside match_files, it is garbage.

It looks like txr is mis-estimating the location of the true stack bottom. Because when I change the loop in mark_mem_region to do this:

while (low <= high + 3) ...

instead of

while (low < high)

the problem goes away. So it looks like the bindings object is referenced in the stack, but deeper than we think.

In fact, this appears to be the real issue. This change alone makes the test cases pass, with or witout optimization, and without that -mpreferred-stack-boundary=8 red herring.

Kaz Kylheku <kkylheku>
Project AdministratorIn charge of this item.
Sun 01 Nov 2009 07:05:56 AM UTC, original submission:

I've been trying txr on x86-64, gcc 4.3.2.

On the first attempt, the program died very early in the execution of the first test case, before doing anything. I turned off optimization in order to investigate with gdb. I quickly suspected an issue with the alignment of objects on the stack so I looked into what compiler options influence this. I recompiled txr with -mpreferred-stack-boundary=8, while leaving optimization off. Now, the first few test cases passed. However, it didn't get through all of them. It crashed due to a live object prematurely turning to garbage. Then I turned optimization on (-O2) and recompiled. This time all test cases passed.

This is counterintuitive: you expect more problems with optimized code. I wonder whether it's a stack issue; could it be that in unoptimized code, pointers are being spilled into unaligned memory locations.

Kaz Kylheku <kkylheku>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by kkylheku (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 03 Nov 2009 06:03:43 PM UTCkkylhekuOpen/ClosedOpen=>Closed
    Mon 02 Nov 2009 03:54:26 AM UTCkkylhekuFixed ReleaseNone=>020
    Sun 01 Nov 2009 05:17:18 PM UTCkkylhekuStatusIn Progress=>Fixed
    Sun 01 Nov 2009 05:03:31 PM UTCkkylhekuPlanned ReleaseNone=>020
    Sun 01 Nov 2009 05:01:35 PM UTCkkylhekuStatusConfirmed=>In Progress

    Back to the top


    Powered by Savane 3.1-cleanup1