Fix missing space in PRINT-OBJECT for TYPE-ERROR. #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Before this change, the output looked like
#<TYPE-ERROR expected-type: "STRING"datum: 97>
phmarek
pushed a commit
that referenced
this pull request
May 9, 2018
Quickstart for the impatient (assuming you've already done a full build): % (cd src/runtime ; make shrinkwrap-sbcl) % src/runtime/shrinkwrap-sbcl This approach relies on the immobile code feature and is very different from the patch series circulated on sbcl-devel. First a native '.core' file is saved, then it is separated (by a Lisp program into two pieces): code components and all else. Immobile code components get written out as assembly source code to make the system assembler do all the heavy lifting of adding DWARF info without which gdb would have problems. All other spaces are written into a '.o' file directly. The '.s' and '.o' files are then linked with the rest of the C runtime. Linking will move the immobile code space arbitrarily, but it is position-independent code. The space is at that time fixed in size to the minimum required to hold its contents. Important note: ELFinated core files can not load fasl files. I plan to allow for that by having COMPILE-FILE write code destined for dynamic space. And eventually we will emit linker relocations so that coreparse does not need to determine where the immobile code resides and perform startup-time relocation (unless it could not get map the other spaces where expected). As just one example of what you can do, using the shrinkwrap-sbcl target you can get a sane (other than every source file being named "shrinkwrap-sbcl.s" allegedly) backtrace from a C debugger. Apparently '.file' directives aren't enough. (gdb) bt > #0 0x00007f31fb8cfc40 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 > #1 0x00000000005906c8 in sb-unix:unix-simple-poll () at shrinkwrap-sbcl.s:22953 > sbcl#2 0x000000000058e355 in sb-sys:wait-until-fd-usable () at shrinkwrap-sbcl.s:22686 > sbcl#3 0x00000000005b7380 in sb-impl::refill-input-buffer () at shrinkwrap-sbcl.s:27806 > sbcl#4 0x0000000000e3e32e in sb-impl::input-char/utf-8 () at shrinkwrap-sbcl.s:340954 > sbcl#5 0x000000000052688b in (lambda # in sb-impl::get-external-format)_2 () at shrinkwrap-sbcl.s:9488 > sbcl#6 0x00000000005c22cc in cl:read-char () at shrinkwrap-sbcl.s:28818
phmarek
pushed a commit
that referenced
this pull request
Dec 15, 2018
The concept remains, but the previous implementation caused the compiler to trip
over its own shoelaces while trying to walk (pun intended), and caused code
analyzers to go awry. It's near impossible to produce a minimal reduction
because by definition all examples seem to involve a lot of hair: macros that
expand inside-out by MACROEXPANDing their arguments, and somehow accidentally
misled the compiler to thinking that the inside code was toplevel.
The failures in previously working code were several. One was an attempt by
the compiler to call GET-DEFINED-FUN on macrolets (redacted backtrace below),
which causes an error in source-path finding, which we might want to fix as a
bug in its own right, except that it goes away after this patch.
Attempting to hack around that in IR1-CONVERT-LAMBDALIKE by simply never calling
GET-DEFINED-FUN on things named (MACROLET x) produces a different error, which
is the attempt to store (MACROLET mumble) into a %DEBUG-NAME of a CLAMBDA:
'The value (MACROLET mumble) is not of type (OR NULL (NOT (SATISFIES SB-INT:LEGAL-FUN-NAME-P)))
when setting slot SB-C::%DEBUG-NAME of structure SB-C::CLAMBDA'
So this changes removes MACROLET as a legal fun name, which makes it never reach
the named lambda case in IR1-CONVERT-LAMBDALIKE, and moreover, MAKE-MACRO-LAMBDA
never returns a top-level-ish lambda from a type derivation perspective.
I can't explain why these never mattered, because it sure looks as if named
macro lambdas always went through the named-lambda path that global functions
did. But at exactly the change which introduced TOP-LEVEL-NAMED-LAMBDA,
without this patch, we would see in various guises:
SB-INT:INVALID-ARRAY-INDEX-ERROR: Invalid index 41 for (SIMPLE-VECTOR 1), should be
a non-negative integer below 1. while executing: COMPILE
Unhandled SB-INT:INVALID-ARRAY-INDEX-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {10006F05B3}>:
Invalid index 41 for (SIMPLE-VECTOR 1), should be a non-negative integer below 1.
Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {10006F05B3}>
0: (SB-C::FIND-SOURCE-ROOT 41 #<SB-C::SOURCE-INFO {100F483203}>)
1: (SB-C::FIND-ORIGINAL-SOURCE (#1=(SB-C::%FUNCALL sbcl#2=#:G23 . sbcl#3=(#:G22))
sbcl#4=(LET ((sbcl#5=#:VAL26 #1#)) (UNLESS sbcl#5# (RETURN-FROM sbcl#6=#:BLOCK24 NIL)))
(BLOCK sbcl#7=#:WRAPPER25 . sbcl#8=(sbcl#4#)) ...))
2: (SB-C::FIND-ERROR-CONTEXT ((MACROLET DEFINE-mumble)) NIL)
3: (SB-C::NOTE-UNDEFINED-REFERENCE (MACROLET DEFINE-mumble) :FUNCTION)
4: (SB-C::FIND-GLOBAL-FUN (MACROLET DEFINE-mumble) NIL)
5: (SB-C::FIND-FREE-FUN (MACROLET DEFINE-mumble) "shouldn't happen! (defined-fun)")
6: (SB-C::GET-DEFINED-FUN (MACROLET DEFINE-mumble) (#:EXPR #:ENV))
7: (SB-C::IR1-CONVERT-LAMBDALIKE (SB-INT:NAMED-LAMBDA (MACROLET DEFINE-mumble)
(#1=#:EXPR sbcl#2=#:ENV) (DECLARE (IGNORE sbcl#2#))
(DECLARE (OPTIMIZE (SB-EXT:INHIBIT-WARNINGS 1))) ...))
phmarek
force-pushed
the
master
branch
2 times, most recently
from
368d8f9 to
b4df8a8
Compare
phmarek
force-pushed
the
master
branch
2 times, most recently
from
76c4d48 to
f5f47f5
Compare
phmarek
force-pushed
the
master
branch
6 times, most recently
from
747669f to
7b0a481
Compare
phmarek
force-pushed
the
master
branch
2 times, most recently
from
c3a0b4d to
2d2d6fb
Compare
phmarek
force-pushed
the
master
branch
3 times, most recently
from
ddb3caa to
e34b390
Compare
phmarek
pushed a commit
that referenced
this pull request
Aug 21, 2020
(read-from-string "#1=#:asymbol") conses only about 8 words plus the gensym name instead of 100 words plus the gensym.
phmarek
pushed a commit
that referenced
this pull request
Aug 26, 2021
The cases which zeroize the result due to oversized constant shift should not care where the input operand is. Also, zeroize will accepts stack TNs. So remember rule #1 of writing a :LOAD-IF, namely: it's always wrong.
phmarek
pushed a commit
that referenced
this pull request
Jun 8, 2022
Rule #1 for logging during signal handling is never call anything in the printf() family of functions, as they might malloc or otherwise be somehow nonreentrant. i.e. FSHOW is just wrong. (And the second rule is never do something to induce so much delay as to make the problem you're investigating irreproducible)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before this change, the output looked like