<div dir="auto"><div class="gmail_quote gmail_quote_container" dir="auto"><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto"><p>To boil down the lessons I drew to the bare essentials: success in one grade does not establish that the C interface is correct.</p></div></blockquote><div>I assume, with "C interface" you mean the C parts of the ODBC library.</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Yes</div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto"><p>I would perhaps try the following:</p><p>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. </p></div></blockquote><div>I've already made a small reproducer, see my original mail. Or do you mean something different? </div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">I was just describing the whole procedure from the start.</div><div dir="auto"><br></div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>And what do you mean by "worker"? (This isn't related to my Mfwpar library, where we have workers). </div><div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">This was fairly loose wording for “a log/trace of the number of Mercury (parallel) runtime execution threads”</div><div dir="auto">“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.</div><div dir="auto"><br></div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>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!</div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto"><p>2. Audit every allocation path around MR_make_aligned_string_copy, including C helpers and callbacks. </p><p></p></div></blockquote><div>What do you mean by "allocation path"? </div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">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 <i>for as long as needed</i>?</div><div dir="auto"><br></div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>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... </div><div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto"> Yes...</div><div dir="auto"><br></div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br></div><div dir="auto"><br></div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto"><p>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.</p></div></blockquote><div dir="auto">What do you mean by "source-buffer"?</div></blockquote></div><div dir="auto"><br></div><div dir="auto"><div dir="auto">the C-source string being copied: pointer valid? string correctly terminated? Lifetime?</div><div dir="auto"><br></div></div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>  </div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto"><p>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.</p></div></blockquote><div>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. </div></div></blockquote></div><div dir="auto"><br></div><div dir="auto"><div dir="auto">"thread apply all bt full" is a GDB command that prints a detailed stack trace for every thread:</div><div dir="auto">thread apply all: run the following command on every thread.</div><div dir="auto">bt (“backtrace”): show the chain of function calls leading to the current execution point.</div><div dir="auto">full: also print local variables, where available.</div><div dir="auto"><br></div></div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>What is "AddressSanitizer" and "UBSan"? Gdb features?</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto"><div dir="auto">Yes.</div><div dir="auto">AddressSanitizer (ASan) and UndefinedBehaviorSanitizer (UBSan) are debugging tools built into GCC and Clang. They add checks:</div><div dir="auto">ASan detects memory errors, like double frees or operations beyond bounds.</div><div dir="auto"><br></div><div dir="auto">UBSan detects certain invalid C operations, such as access to a misaligned pointer.</div></div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto"><p>This requires some GDB know-how but knowing your coding mastery, Volker, I assume this to be entirely feasible by you.</p></div></blockquote><div>Yes, it should be.</div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto"><p>).</p></div></blockquote><div>You haven't initiated a thread in the past few years... replies only. So says my mail client.</div></div></blockquote></div><div dir="auto"><br></div><div class="gmail_quote gmail_quote_container" dir="auto"></div><div dir="auto">That was a mercury-dev list thread.</div><div dir="auto"><br></div><div dir="auto">Good luck</div><div dir="auto">Fabrice </div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div></div></blockquote></div><div class="gmail_quote gmail_quote_container" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div><span></span></div></div>
</blockquote></div></div>