Euphoria
Ticket #453:
Coverage crashing
-
Reported by
mattlewis
Nov 28, 2010
When running the interpreter with -coverage, it is crashing:
Fatal run-time error:
A machine-level exception occurred during execution of this statement
Unable to open coverage database!
When running the interpreter with -coverage, it is crashing:
Fatal run-time error:
A machine-level exception occurred during execution of this statement
Unable to open coverage database!
Actually, there seems to be some problem inside of db_insert():
io:seek(current_db, index_ptr)
r = 0
while TRUE do
nrecs = get4()
records_ptr = get4()
r += nrecs
if r + 1 >= key_location then
exit
end if
end while
The value of r goes from 0, to 40, to 1831822741, which doesn't seem correct. The DB appears to be 505 bytes when this crashes at this line:
io:seek(current_db, records_ptr+4*(key_location-1))
for i = key_location to nrecs+1 do
put4(key_pointers[i+r-nrecs]) -- <-- CRASH HAPPENS HERE
end for
In some cases, the file ends up being 760MB, presumably from writing after an incorrect seek makes a really huge file.
Details
1. Comment by mattlewis
Nov 28, 2010
Looks like it was just a corrupted database.
2. Comment by mattlewis
Nov 28, 2010
The coverage writing code seems to work when interpreted, so this may be a translator issue.
3. Comment by mattlewis
Nov 29, 2010
Files were closing too early.
4. Comment by DerekParnell
Nov 29, 2010
I'm not so sure your fix hasn't now got side effects.
Is the main file one of the included files?
What about other user files that are still opened while the abort message is waiting for a console response? This was the primary reason for closing all files just prior to aborting an application.
5. Comment by jimcbrown
Nov 30, 2010
I agree with Derek. Files opened with eu:open() by the user application should be automatically closed at this point, since no futher user application code will be run (I'm assuming even crash_routine() would have been called and finished by this point).
I guess the key issue here is that we don't seem to have an easy way to distinguish between files opened by the user application and files opened by the euphoria frontend (such as the edb used for messages or the edb used for the coverage database). (Sorta like we can't distinguish between callbacks created by the frontend - translated code - versus callbacks made by the euphoria application, as I discovered when working in the coverage branch.)
6. Comment by mattlewis
Nov 30, 2010
Yes, sorry that includes the main file, if it is still open. The place where this stopped closing anything was when something like CompileErr() was called during parsing.
There can be no user opened files at this point, since none of their code has started executing. The back end still closes all opened files as before, but we call the coverage routines before this happens.
GitHub