#432 closed defect (fixed)
tol crash after compiling a just decompiled file
Reported by: | Jorge | Owned by: | Víctor de Buen Remiro |
---|---|---|---|
Priority: | highest | Milestone: | |
Component: | Kernel | Version: | head |
Severity: | blocker | Keywords: | |
Cc: |
Description
This bug was reported by Cesar. The file is attached.
Attachments (1)
Change History (7)
Changed 19 years ago by
comment:1 Changed 19 years ago by
Status: | new → assigned |
---|
comment:2 Changed 19 years ago by
It's a problem of freeing memory used for "Matrix cov".
More specifically, when session is decompiled (what we call remove objects from the current session) nRefs_ attribute of "Matrix cov" doesn't reach the 0 value and is not removed.
I've tried with Tol v1.1.3 and it works properly.
The calling stack under v1.1.3 seems to be more depth when deallocating than in the current version. Looks like a missing cast step in some point during deallocating under the current version.
This stuff is mostly related with the changes done to improve the templates implementation. Víctor, could you put one of your eyes into this?
comment:3 Changed 19 years ago by
Owner: | changed from danirus to Víctor de Buen Remiro |
---|---|
Status: | assigned → new |
Better, I will put both my two eyes
comment:4 Changed 19 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Bug has been fixed in CVS.
In binary operators evaluation (btol/bgrammar/graimp.cpp, close to line 610) is made a previous evaluation of first argument to get its type. This object must be deleted before to make the true binary evaluation to avoid excesive references.
Due to this cov object ends with references and cannot be deleted during decompilation. In second compilation TOL attempts to send a warning notifing that cov already exists but it has been defined in a file that no longer exists and then crashes by an invalid memory access.
To avoid this second problem, BSourcePath objects are stored in a static ordered array that includes also a flag to control if object is already alive.
To solve this problem has been necessary to introduce a method of powerful debuging, generating a data base of historical events of creation, destruction, increase and decrement of references, etc.; for each object TOL and controlable from the own language. This will be useful to persecute similar errors.
Thanks to report it.
comment:5 Changed 18 years ago by
bug_file_loc: | → http://cvs.tol-project.org/viewcvs.cgi/tol_tests/toltcl/Bugzilla/bug_000432/?only_with_tag=TOL-REL-1-1-4_BRANCH_20061130 |
---|
comment:6 Changed 18 years ago by
bug_file_loc: | http://cvs.tol-project.org/viewcvs.cgi/tol_tests/toltcl/Bugzilla/bug_000432/?only_with_tag=TOL-REL-1-1-4_BRANCH_20061130 → http://cvs.tol-project.org/viewcvs.cgi/tol_tests/toltcl/Bugzilla/bug_000432 |
---|
for bug 432