TRACE on external symbols of the COMMON-LISP package should signal an error
Bug #1784517 reported by
Paul F. Dietz
This bug report is a duplicate of:
Bug #309469: TRACE of certain functions crashes SBCL into LDB.
Edit
Remove
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
New
|
Undecided
|
Unassigned |
Bug Description
As noted in chat, the standard says the results are undefined when TRACE is invoked on an external symbol of the COMMON-LISP package. However, doing (TRACE ASH) causes memory faults when ASH is then called from the command line.
SBCL should signal an error when attempting this undefined behavior, rather than putting the image into a state where faults occur.
To post a comment you must log in.
No it shouldn't. Absolute worst, a warning, but preferably not that either. The "undefined behavior" can be usefully exploited.
* (trace open)
* (open "/dev/null")
0: (OPEN "/dev/null")
0: OPEN returned #<SB-SYS:FD-STREAM for "file /dev/null" {10018BE193}>
#<SB-SYS:FD-STREAM for "file /dev/null" {10018BE193}>
works perfectly well, and is more convenient than running SBCL under strace.
As to the fact that tracing ASH causes stack overflow, there are plenty of other behaviors that would be more useful than signaling an error
- "wire in" all calls from any system function to any other system function such they they bypass the level of indirection normally imposed specifically so that functions can be redefined and calling by name gets the redefined callee. This would be a pain to deal with for developers.
- silently don't trace functions known to cause stack overflow. Build that list up over time as people report problems. (Because maybe every call to ASH was transformed into something internal that is not ASH. Just pretend it was)
To me this would be a wontfix though.