[m-users.] Segmentation violation on FFI wrapper for linenoise-ng

[Sean Charles (emacstheviking)]

Hi Zoltan,

I will check those files for sure. The memory I am freeing was allocated within C world by the linenoise-ng library not by Mercury, I am merely following best practice on that, https://github.com/antirez/linenoise <https://github.com/antirez/linenoise> ...

	>The returned line should be freed with the free() standard system call. However sometimes it could happen that your program uses a different dynamic allocation library, so you may also used linenoiseFree to make sure the line is freed with the same allocator it was created.

For whatever reason (I checked the header) the linenoise-ng variant that supports UTF-8 does not provide linenoiseFree() so I used free() as shown in the orginal example.c

INTERESTING: I played around a little and discovered via some blunderbuss printf() in the C code that it ONLY segfaults if I use CTRL-D as soon as the repl starts:

{13:50}~/Documents/code/mercury/f2:ast-start ✗ ➭ ./felt -r

FELT ➭ Version: v3.14.0 - Sean Charles 2021
Be prepared for a most excellent journey....

FELT ➭ **PRESSED CTRLD-D HERE**

*** Mercury runtime: caught segmentation violation ***
cause: address not mapped to object
address involved: 0x0
This may have been caused by a stack overflow, due to unbounded recursion.
exiting from signal handler
[1]    70777 segmentation fault  ./felt -r

If I run it again and press RETURN on a blank line then pressing CTRL-D does not cause the issue:

{13:53}~/Documents/code/mercury/f2:ast-start ✗ ➭ ./felt -r

FELT ➭ Version: v3.14.0 - Sean Charles 2021
Be prepared for a most excellent journey....

FELT ➭ **PRESSED RETURN**
LNG: NULL:0, len:0, 
FELT ➭ **PRESSED CTRL-D**
LNG: NULL:1, len:0, 

FELT ➭ Be excellent to one another.


This smells!  :D.  Not sure which variety of fish it is yet though. I suspect I MAY have found some edge case bug in the the library, fortunately for me I built it from source and am more than comfortable with C and C++ so I will focus on that later this weekend but for now I may continue with my project once again.

Thanks for your help. I took onboard your previous comments about not throwing exceptions and my ast builder is taking shape too.

Sean.



> On 19 Jun 2021, at 12:22, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> 
> 2021-06-19 20:57 GMT+10:00 "Sean Charles (emacstheviking)" <objitsu at gmail.com>:
>> Does Mercury have something to with this e.g. a SIGINT handler or something 
> 
> Yes, Mercury does set signal handlers, though whether they are involved
> in this problem is a different question. Have a look at runtime/mercury_signal.[ch],
> and at the code in other source files that use that module's functionality.
> 
>>    % ln_free: Release a previosuly read line.
>>    % In order to prevent memory leaks, after the REPL has dealt with the
>>    % user input this must be called to hand the memory back to the pool.
>>    %
>> :- pragma foreign_proc(
>>    "C",
>>    ln_free(Line::in, IOin::di, IOout::uo),
>>    [will_not_throw_exception, promise_pure],
>>    "
>>    free(Line);
>>    IOout = IOin;
>>    "
>> ).
> 
> Mercury does NOT use malloc to allocate memory for strings.
> If you call free to try to deallocate a string that was allocated by Mercury,
> a SIGSEGV would be far from surprising.
> 
> In general, you must not try to deallocate anything allocated by Mercury;
> instead, you let the Boehm collector collect it. (The gc.m module in
> the Mercury standard library has a predicate that asks for an immediate
> collection, but that is quite different from collecting one memory block.)
> 
> Zoltan.

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