libera/#clasp - IRC Chatlog
Search
17:26:15
Colleen
Bike: drmeister said at 2021.09.12 05:26:25: I caught the "section table goes past the end of file" The test that is failing is in llvm ELF.h:809 if (SectionTableOffset + SectionTableSize > FileSize). The values follow but the overflow is only 16 bytes. Grrr
18:34:33
Bike
drmeister: why were function descriptions moved into entry points, again? a function having multiple entry points would need the same description in every entry point, right?
20:57:01
drmeister
If a function needs multiple call/entry points the idea was you put them in a vector in the entry-point object. So there would be one function description pointer for all the call/entry points.
20:57:40
drmeister
I'm working to track down the "section table goes past end of file" and it looks nasty. I can go into why it looks nasty when you are online.
20:58:53
drmeister
I can compile-file-serial all of the regression tests in one pass of and then run the tests without compiling them, just loading them. The "section table goes past end of file" happens anyway.
20:59:15
drmeister
If I remove some of the tests before debug.lisp - the problem goes away or becomes intermittent.
20:59:40
drmeister
It feels like an llvm problem when you give it too many object files it messes up or something.
21:54:25
drmeister
I setup load-if-compiled-correctly and nhc-load-if-compiled-correctly so I can switch compile-file-serial on and off.
22:00:35
drmeister
I can put a break on llvm::object::createError and catch the error and then backup and check this test:
22:06:23
drmeister
This must be an object file generated on the fly during loading because the debug.fasp object file is 851304 bytes
22:08:13
drmeister
Now hold on there - this isn't a compilation object file. It's from make_lisp_frame.
22:35:11
drmeister
It's a particular frame that causes this problem. Many frames work fine. But the one that is bad is always the same one.
22:35:40
drmeister
DWARFContext/"/home/meister/Development/clasp/src/lisp/regression-tests/framework.fasp"@21-21
22:36:01
drmeister
It's fine the first time the dwarf.lisp file evaluates - the second time this one throws up these errors.
22:38:34
drmeister
The start and size of the object file don't change from when it works to when it doesn't. That suggests that the SectionTableSize or SectionTableOffset has changed - or the object file was damaged.
22:39:08
drmeister
I'll calculate a checksum of each object file and print that to check for the contents of the object files changing.
23:14:45
drmeister
../../src/core/backtrace.cc:154:args_from_offset When trying to get arguments from CL frame read what should be a closure 0x7ffd9d16fa40 but it isn't
23:16:04
drmeister
Ok, the object file memory is being written into between the first time it runs successfully and the second time that it screws up.
23:18:01
drmeister
So the object file in memory for framework.fasp is being damaged because the crc32 is changing from 5735e8ad to 8bc17eb6
23:20:02
drmeister
All of the object files I see are aligned to a page boundary so I could mprotect them and detect when they are being written to.