Re: more on MT debugging

[Pascal B. <pj...@in...>]

> On 14 Feb 2019, at 21:20, Don Cohen <don...@is...> wrote:
> 
> Pascal Bourguignon writes:
> 
>> Specifically, any function in the CL package can be called
>> internally thru other mechanisms than provided to the user code:
>> the C code can call directly the C implementation of the CL
>> functions, without passing thru the CL API. Hence TRACE is allowed
>> NOT to work in those cases!
> ...
> 
>> Instead, you can use gdb to break on those C functions.
> 
> I suppose that further, internal functions could be called from other 
> functions, e.g., intern might call internal functions in hashtabl.d,
> so it wouldn't be good enough to break only the external functions.
> 
> Is the current theory that only the file hashtabl.d has to be fixed 
> for MT ?  Would it be worth while to try my test with a gdb break on 
> every function in that file?
> 
> Does anyone have any other suggestions for trying to track down the
> cause of a segfault once I can reproduce it?  



Now, perhaps it would be a little difficult to apply to the sources of clisp, (would valgrind be appliable?), but I would start by compiling with a recent gcc (eg. gcc-8.2) using a whole complement of -fsanitize options, and correct all the problems found there first. I’d suggest the following as a basis.

sanitize_ld=(
        -fsanitize=leak
)

sanitize_cc=(
    -fsanitize=address
    -fsanitize=null
    -fsanitize=bounds
    -fsanitize=vla-bound
    -fsanitize=object-size

    -fsanitize=unreachable
    -fsanitize=return # C++ only

    -fsanitize=shift
    -fsanitize=shift-exponent
    -fsanitize=shift-base
    -fsanitize=integer-divide-by-zero
    -fsanitize=signed-integer-overflow

    -fsanitize=float-divide-by-zero
    -fsanitize=float-cast-overflow
    -fsanitize=nonnull-attribute
    -fsanitize=returns-nonnull-attribute
    -fsanitize=bool
    -fsanitize=enum
    -fsanitize=vptr # C++ only


    -fsanitize-address-use-after-scope
    -fsanitize-undefined-trap-on-error
    -fstack-protector-all
    -fstack-check
)


Once the program can be compiled and run successfully with those correction, to debug the remaining segfault, you would run it under gdb to be able to inspect the stack when the segfault occur, and try to locate the place in the source where it occured.  This may also be done on the core file, but it is easier to debug in a live process.

-- 
__Pascal J. Bourguignon__