#223 Seg fault on graphic close after using IPL barchart

[Brian Tiffin]

There is a small performance summary chart in the UP docs, and it is failing on window close. Something in the 2D graphics layer seems to be amiss. I haven't run the code to get an image capture in a while, but this was working a few months ago (as far as I recall). I'm on rev [r5031] at the moment.

Code attached. The barchart issue may be a red herring, not sure.

I haven't spent any time in the debugger yet, as I'm hoping it's an obvious fix. If not, add a note, and I'll see what I can figure out, or at least try and narrow it down.

[Jafar]

Hi Brian, this is not reproducing for me on an Ubuntu 16.04 machine. What is your "unicon -features" ?

[Brian Tiffin]

prompt$ $ unicon -features
Unicon Version 13.0.  Feb 1, 2017
UNIX
POSIX
DBM
ASCII
co-expressions
native coswitch
concurrent threads
dynamic loading
environment variables
event monitoring
external functions
keyboard functions
large integers
multiple programs
pattern type
pipes
pseudo terminals
system function
messaging
graphics
3D graphics
X Windows
libz file compression
JPEG images
PNG images
SQL via ODBC
Audio
secure sockets layer encryption
CCompiler gcc 5.4.0
Physical memory: 7808675840 bytes
Revision 5031
Arch x86_64
CPU cores 4
Binaries at /home/btiffin/unicon/bin/

prompt$ unicon -s charting.icn -x

Run-time error 302
File charting.icn; Line 106
memory violation
Traceback:
   main()
   close(window_-1:-1()) from line 106 in charting.icn

I'll try and dig in, and narrow it down, Jafar.

[Brian Tiffin]

With -g turned up:

Starting program: /home/btiffin/wip/writing/unicon/examples/performance/charting
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000435154 in buckdelete (wd=wd@entry=0x6acaf0, wc=0x6d1560) at rxrsc.ri:48
48             wd->colors[wd->colors[wd->buckets[i]].next].prev = wc->prev;
(gdb) bt
#0  0x0000000000435154 in buckdelete (wd=wd@entry=0x6acaf0, wc=0x6d1560)
    at rxrsc.ri:48
#1  0x00000000004362e2 in free_xcolors (w=w@entry=0x6a80e0, extent=extent@entry=2)
    at rxrsc.ri:564
#2  0x0000000000444cbd in wclose (w=0x6a80e0) at rxwin.ri:1095
#3  0x0000000000413741 in F2q0_close (f=f@entry=0x7fffffffd6c8,
    r_rslt=0x6953e0 <trashcan>) at fsys.r:149
#4  0x00000000004113f1 in P000_main () at charting.c:3099
#5  0x00000000004090d2 in main (argc=1, argv=0x7fffffffdbd8) at charting.c:101

charting.icn pass

Only happens when two Fg colour functions are used:

# draw the bars...
Fg(win, "blue")
...

# labels
Fg(win, "black")
...

Using both Fg functions causes an issue, none or either, does not.

Hope that helps tracking down the issue

[Jafar]

Brian, I didn't forget about this but I couldn't get it to reporduce for me. Do you know which of these pointers is bad?

wd->colors[wd->colors[wd->buckets[i]].next].prev = wc->prev

wd and wc are passed to the fucntion and they looked good. But there are colors with prev/next and bucket with prev/next and one of those is going bad probably. Can you please narrow it down?

Thanks!

[Bruce Rennie]

I have just tested this on my Centos 6.9 system and have got the following error

charting

Run-time error 142
File charting.icn; Line 105
attempt to read/write on closed window
offending value: window_-1:-1()
Traceback:
main()
Event(window_-1:-1()) from line 105 in charting.icn

[Charles Evans]

I get the same error as Bruce got,
kubuntu zesty 64 on [r5615],
concurrent debug build.

[Charles Evans]

Brian, would it be ok for me to put
charting.icn
in tests/graphics?
We need much more test coverage here.

[Brian Tiffin]

Absolutely ok. I tagged the sources as public domain.

[Charles Evans]

Bug [#228], gpxtest gives me the same error on close via 'X' button.

[Charles Evans]

Brian, I am using gcc 6.3, no segfault.
I almost recall a use-after free bug in windows attribs; maybe 5 years ago?
maybe something in my notes...
./configure --enable-debug
# ^ thanks, Jafar!
make Unicon
valgrind src/runtime/iconx charting
# ^ 61 errors. (Note that
valgrind charting
does not give src line#s for errors.)

[Charles Evans]

Thanks, Brian, charting.icn is in [r5620].

[Charles Evans]

The use after free was bug [#97],
but AFAICT you did not call WAttrib().
Could be another use after free, of course.

[Jafar]

Still no luck in reproducing this on a coule of Ubuntu 64-bit machines.

[Charles Evans]

[r5625], debug build:
valgrind --track-origins=yes $BASE/src/runtime/iconx ./charting
# ^ no errors until close:

==26460== Command: /aufs/uni5197nd/src/runtime/iconx ./charting
==26460== 
==26460== Invalid read of size 8
==26460==    at 0x1EFDE4: handle_misc (rxwin.ri:848)
==26460==    by 0x1F0302: wgetq (rxwin.ri:977)
==26460==    by 0x21196D: wgetevent (rwindow.r:136)
==26460==    by 0x17561F: ZEvent (fwindow.r:1579)
==26460==    by 0x1908C6: interp_0 (interp.r:1314)
==26460==    by 0x188A3A: main (imain.r:536)
==26460==  Address 0xb8ad260 is 32 bytes inside a block of size 40 free'd
# ^ -----------------
==26460==    at 0x4C2ED5B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26460==    by 0x25B149: free_binding (grttin.h:595)
==26460==    by 0x1F0984: wclose (rxwin.ri:1098)
# ^ --------------
==26460==    by 0x1EFDC0: handle_misc (rxwin.ri:846)
==26460==    by 0x1F0302: wgetq (rxwin.ri:977)
==26460==    by 0x21196D: wgetevent (rwindow.r:136)
==26460==    by 0x17561F: ZEvent (fwindow.r:1579)
==26460==    by 0x1908C6: interp_0 (interp.r:1314)
==26460==    by 0x188A3A: main (imain.r:536)
==26460==  Block was alloc'd at
==26460==    at 0x4C2FB45: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26460==    by 0x25AFE8: alc_wbinding (grttin.h:575)
==26460==    by 0x1F0CAE: wopen (rxwin.ri:1173)
==26460==    by 0x15D17C: Zopen (fsys.r:629)
==26460==    by 0x1908C6: interp_0 (interp.r:1314)
==26460==    by 0x188A3A: main (imain.r:536)

HTH

[Jafar]

 case ClientMessage: {
    /*
     * only client message we handle at present are destroy requests
     */
    struct descrip d;
    int ret = 0;
    if (w && (evwin == w->window->win)) ret = 1;
        if (ws->inputmask & WindowClosureMask) {
       MakeInt(WINDOWCLOSED, &d);
           qevent(wb->window, &d, 0, 0, 0, 0);
           return 1;
           }
    SETCLOSED((wbp)wb);
    wclose(wb);
    MakeInt(WINDOWCLOSED, &d);
    qevent(wb->window, &d, 0, 0, 0, 0);       <======  line #848
    BlkD(lastEventWin,File)->status &= ~(Fs_Write);
    if (ret) return 1;
    break;
    }

[Jafar]

we are doing qevent() after a wclose() two lines above. Not sure if that is valid. Want to try moving that after BlkD line and see what happens?

[Charles Evans]

qevent after BlkD...
same error, now at line 850, qevent line

[Jafar]

Can you run under gdb to print the values of the variables? Is wb null or trash ?

[Charles Evans]

Brian, do you have any environment variables set as MALLOC*?
set | grep MALLOC
Did you use default configure?

[Brian Tiffin]

No env vars re MALLOC, and yes on default ./configure.

Well except I'm now running a build with --enable-debug to run some gdb.

But good point, I'll start digging through environment space and dot-files to see if some local setting is triggering the fault here.

And it is still happening with latest. On q to quit in gdb:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004d24ca in buckdelete ()
Missing separate debuginfos, use: dnf debuginfo-install libXcursor-1.1.14-6.fc24.x86_64
(gdb) bt
#0  0x00000000004d24ca in buckdelete ()
#1  0x00000000004d3d34 in free_xcolors ()
#2  0x0000000000449b79 in wclose ()
#3  0x000000000048ef5b in F2r_close ()
#4  0x00000000004da905 in invoke ()
#5  0x0000000000423607 in ?? ()
#6  0x000000000041bbad in main ()

[Charles Evans]

Breakpoint 1, handle_misc (wd=0x555555950fa0, w=0x555555943ac0) at rxwin.ri:850
# ^ after wclose, qevent :
850 if (ret) return 1;
(gdb) print wb
$1 = (wbp) 0x555555943ac0 # unchanged
(gdb) print wb->window
$2 = (wsp) 0x5555559466f0 # reasonable
(gdb) cont
Continuing.
Run-time error 142
...

What puzzles me is:
Brian gets a segfault in wclose();
valgrind reports no error there, but
a use-after-free (non-fatal)
in the following qevent()
then many more before a
run-time error stop.

Brian, what version window manager, X, etc., do you have? what color depth? bpp?
Have you tried charting with another xserver? another color depth?

[Charles Evans]

Jafar, qevent's 1st arg, wb->window, was already freed, by
free_window() in wclose(), refcount was 0.
The freed wb->window's refcount is trashed now, over 1 billion, when qevent is called.

[Charles Evans]

wb->refcount is also trashed, over 1 Billion.

If wb->window->refcount was 1 and wclose() returns 0, wb is gone.

AFAICT wclose() return value is never used, so we could fix it to only return 0 if wb is really gone.

[Charles Evans]

If I use q to quit, valgrind shows 0 errors, normal exit, success.
Closing by clicking X : 41 errors,
runtime error.