Re: Re: [code] [textadept] Sometimes Crash on textadept.run.close()

From: Mitchell <m.att.foicica.com>
Date: Sat, 20 Oct 2018 14:39:33 -0400 (EDT)

Hi Johannes,

On Fri, 19 Oct 2018, johannes wrote:

> Hello Mitchell,
>
> until know I hadn't any crash. But one time I had a freeze. This was after I
> called reset() and then called 'run_project_call' from my module . I've used
> textadept_NIGHTLY_2018-10-18.x86_64. Here's the backtrace:
>
> [snip]

Thanks. When you call `reset()` with any processes still running, I'd expect strange things to happen. It looks to me like Textadept is receiving stdout/stderr from a previously spawned process, and when it attempts to call the proper handler function, the lookup fails because the previous call to `reset` deleted it. One solution I can think of is to just kill any running process when `reset` is called, but there still may be other processes running that were previously invoked (`textadept.run.stop()` only kills the most recent one).

Cheers,
Mitchell

>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000006f10ff in index2addr (L=0x243a65726f662c29, idx=-1001000)
>     at lua/src/lapi.c:61
> 61    lua/src/lapi.c: Datei oder Verzeichnis nicht gefunden.
> (gdb) bt
> #0  0x00000000006f10ff in index2addr (L=0x243a65726f662c29, idx=-1001000)
>     at lua/src/lapi.c:61
> #1  0x00000000006f2990 in lua_rawgeti (L=0x243a65726f662c29, idx=-1001000,
>     n=779248998) at lua/src/lapi.c:661
> #2  0x0000000000720073 in ch_read (source=0x180fe50, cond=G_IO_IN,
>     data=0x18102f8) at lua/src/loslib.c:645
> #3  0x00007ffff55bece5 in g_main_context_dispatch ()
>    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #4  0x00007ffff55bf048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #5  0x00007ffff55bf30a in g_main_loop_run ()
>    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #6  0x00007ffff78c8447 in gtk_main ()
>    from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
> #7  0x00000000006f10b4 in main (argc=1, argv=0x7fffffffe158)
>     at textadept.c:2491
> #8  0x00007ffff488ef45 in __libc_start_main ()
>    from /lib/x86_64-linux-gnu/libc.so.6
> #9  0x00000000005cedd5 in ?? ()
> #10 0x00007fffffffe148 in ?? ()
> #11 0x000000000000001c in ?? ()
> #12 0x0000000000000001 in ?? ()
> #13 0x00007fffffffe436 in ?? ()
> #14 0x0000000000000000 in ?? ()
>
>
> Am 18.10.2018 um 15:32 schrieb Mitchell:
>> Hi Johannes,
>>
>> On Wed, 17 Oct 2018, johannes wrote:
>>
>>> Hi Mitchell,
>>>
>>> have noticed that you're currently working on os.spawn. Maybe the
>>> following
>>> bug I encountered is somehow related to this, since os.spawn is also about
>>> processes:
>>>
>>> In my module 'textadept-dev-tools' (on github) I've created customized
>>> run-,
>>> compile- and build-commands. (see file 'tools_project.lua', Line 98, 106,
>>> 114). Recently I've added the lines 'textadept.run.stop()' to these
>>> functions. Since then there are sometimes crashes of textadept (totally
>>> closes) when calling these functions. I've used them long enough before
>>> without calling textadept.run.stop(), thereby weren't any crashes. But
>>> then
>>> there was allways a new process added (haven't noticed this until my RAM
>>> was
>>> full).
>>>
>>> I got into this issue with textadept_10.1.x86_64 on Linux.
>>
>> If you have gdb installed (the GNU debugger), I would recommend downloading
>> a nightly build, which has debug symbols built-in, opening a terminal and
>> running `gdb textadept`, followed by `r`. Textadept will run normally and
>> try hard to induce a crash. When you do, type `bt` in the terminal and
>> report the backtrace to me.
>>
>> Cheers,
>> Mitchell
>
>

Mitchell

-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Sat 20 Oct 2018 - 14:39:33 EDT

This archive was generated by hypermail 2.2.0 : Sun 21 Oct 2018 - 06:52:07 EDT