fix #32678, error due to Ptr constant in _reformat_bt

[JeffBezanson]

Also change jl_get_backtrace to return a pair of values instead of mutating. This seems to have been missing a write barrier, plus jl_backtrace_from_here is very similar and already returns a pair, so might as well make them match.

fix #32678

[Keno]

So the issue is that we make this -1 Ptr into a literal and then don't serialize it properly. That seems ... bad?

[JeffBezanson]

Yes, we save all pointers as NULL so that we can detect that an object is uninitialized at run time, and re-create the needed native objects. Interestingly dump.c has this:

        if (t->name == jl_pointer_typename && jl_unbox_voidpointer(v) != (void*)-1) {
            // normalize most pointers to NULL, to help catch memory errors
            // but permit MAP_FAILED / INVALID_HANDLE to be stored unchanged

but staticdata.c doesn't have the special case for -1. @vtjnash & I discussed limiting this somehow, e.g. only nulling mutable object fields.

[Keno]

This one is particularly bad because the user didn't write @eval :($(Ptr{Cvoid}(-1%UInt))), but just the code Ptr{Cvoid}(-1%UInt). The fact that we construct and inline that pointer in the IR is just something the compiler does. Perhaps we need to prevent inference from creating Const Ptrs?

[vtjnash]

yeah, stopping inference from embedding pointers would probably be a better plan

[c42f]

I'm a little surprised the static analyzer is ok with this; I believe these should be marked with JL_REQUIRE_ROOTED_SLOT? I can add that tweak in #33277 where I'm touching the same code anyway.

[KristofferC]

Can this be backported? It happens all the time when dealing with package compilation stuff.

[c42f]

Yes I think it would be sufficient to backport only the single line with the if UInt(ip) == (-1 % UInt). The rest is code cleanup.