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

[Volker Wysk]

Hi

I have a problem with my improved ODBC library. 

When I compile it in the grade asm_fast.par.gc.stseg, using an old compiler
(rotd-2026-02-28), which doesn't refuse to do so, then it works on my
Ubuntu 26.04 box. No problems.

When I compile the same program in the grade hlc.par.gc, it crashes with a
segmentation fault. That doesn't happen immediately. And it happens
regardless of which compiler is used (rotd-2026-08-06 or rotd-2026-02-28).

I have a test database with a test relation, which has one column (a
string). I execute a simple SQL query, which just retrieves all the rows,
sorted. The crash always happens after roughly the same number of rows have
been retrieved inside the library, but it's a little different each time.
When I fill in 100,000 rows, the segfault occurs after receiving at bit
more than half of them. When I use 10,000 rows, the problem doesn't occur.
When I use 50,000, it occurs after some 7800 have been retrieved.

I've also tried it with the old, unimproved odbc "extra" library. Here, the
problem doesn't occur. But you must compile it in a non-parallel grade,
otherwise the program hangs.

I'm really helpless here. I have no idea of how to debug this. I tried to
pin down the place of the crash, by adding debug output (since the
debugger doesn't work with programs compiled in parallel grades). I haven't
been successful with it, so far. It happens at different places.

So I'd like to know what's the difference between asm_fast.par.gc.stseg and
hlc.par.gc here. Do the symptoms hint at a memory management issue?

There are some parts of the improved library, which make use of low-level
runtime parts. I've taken them over from the old odbc library. For
instance, there is MR_make_aligned_string_copy, which is declared in
mercury_string.h. It's only concisely documented there. For instance, there
is the following in the comments for it, what doesn't make much sense to
me:

// BEWARE: this may modify `MR_hp', so it must only be called from places
// where `MR_hp' is valid. If calling it from inside a C function, rather than
// inside Mercury code, you may need to call MR_{save/restore}_transient_hp().

How should I tackle the problem? Should I try to understand memory
management in the old parts of the new odbc library? Are there any ways to
find out where exactly the segfault happens? What could the cause be
like, particularly in regard to the fact that it works in the asm_fast
grade and doesn't in the hlc grade?

Thanks,
Volker