[m-users.] Crash in improved ODBC library when compiled in hlc.par.gc grade

[Fabrice Nicol]

> To boil down the lessons I drew to the bare essentials: success in one
> grade does not establish that the C interface is correct.
>
> I assume, with "C interface" you mean the C parts of the ODBC library.
>

Yes

> I would perhaps try the following:
>
> 1. Make a small standalone reproducer with fixed database contents, query
> and ordering. Include a worker count. Cleanly rebuild all Mercury
> components for each grade. Compare hlc.par.gc with hlc.gc where supported,
> and vary worker count separately; repeat the original asm_fast comparison
> with the same compiler.
>
> I've already made a small reproducer, see my original mail. Or do you mean
> something different?
>

I was just describing the whole procedure from the start.

And what do you mean by "worker"? (This isn't related to my Mfwpar library,
> where we have workers).
>

This was fairly loose wording for “a log/trace of the number of Mercury
(parallel) runtime execution threads”
“Worker count” meant how many execution threads the runtime uses—not the
number of database rows, queries or ODBC connections, sorry for any
ambiguity here.


> I've built and run the test program (reproducer) in the hlc.gc grade. It
> runs and exhibits what looks very much like the same segmentation fault
> problem. That's interesting. Now what does that tell us about possible
> causes? (Zoltan?) And now I can use the Mercury debugger!
>
> 2. Audit every allocation path around MR_make_aligned_string_copy,
> including C helpers and callbacks.
>
> What do you mean by "allocation path"?
>

I meant the sequence of code that reaches that call to
MR_make_aligned_string_copy, supplies its input, allocates the Mercury
string, and passes the result back to Mercury.
Notably:  is the source pointer valid, and is the string correctly
terminated? is the allocated heap state valid for that grade and calling
context? After the copy, is the updated heap state preserved, and does the
returned string remain accessible to GC *for as long as needed*?

And MR_make_aligned_string_copy is only an example of what seem to be
> compiler-internals that have been made use of in the original, unimproved
> ODBC library. I'll have to audit them all...
>

 Yes...


>
> 3. Check source-buffer termination & lifetime (if you can determine it
> robustly) and how returned Mercury strings remain reachable (under thevsame
> provision). This may be the hardest thing to do for parallel grades, see
> why below 5.
>
> What do you mean by "source-buffer"?
>

the C-source string being copied: pointer valid? string correctly
terminated? Lifetime?


>
> 3. Build with C debug symbols and capture the SIGSEGV in gdb (or a core
> dump), including "thread apply all bt full".  Log row number, column,
> buffer capacity and reported length immediately around fetch/copy
> operations.  Use AddressSanitizer/UBSan to seek the first invalid access.
>
> Again a phrase I don't understand: "thread apply all bt full"? I don't
> have any experience with gdb. But using it here looks like a good idea. But
> (of course) I'll try the Mercury debugger first.
>

"thread apply all bt full" is a GDB command that prints a detailed stack
trace for every thread:
thread apply all: run the following command on every thread.
bt (“backtrace”): show the chain of function calls leading to the current
execution point.
full: also print local variables, where available.


> What is "AddressSanitizer" and "UBSan"? Gdb features?
>

Yes.
AddressSanitizer (ASan) and UndefinedBehaviorSanitizer (UBSan) are
debugging tools built into GCC and Clang. They add checks:
ASan detects memory errors, like double frees or operations beyond bounds.

UBSan detects certain invalid C operations, such as access to a misaligned
pointer.

> This requires some GDB know-how but knowing your coding mastery, Volker, I
> assume this to be entirely feasible by you.
>
> Yes, it should be.
>
> ).
>
> You haven't initiated a thread in the past few years... replies only. So
> says my mail client.
>

That was a mercury-dev list thread.

Good luck
Fabrice

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20261021/2867174d/attachment-0001.html>