Buffer overflow on Neko target, not on CPP

[Horsetopus]

Environment: Ubuntu 16.04.1 LTS running as a VirtualBoxVM on a Windows 10 Host. The VM uses only one CPU. haxelib_client: [3.2.0-rc.3]

I am having an issue with my server application. It's meant as a communication tool, connecting many users, and for each user a connection is established with another software running locally. All this creates a lot of threads, for all the websockets, and also for long tasks I don't want hanging on the main thread.

Although the CPU remains low, and the memory usage seems stable, and although it's able to run indefinitely when building on CPP ( last test ran for 12 hours, 30000 threads created without issues ), when running on Neko, after something from 15 to 25 minutes usually, I get a buffer overflow exception thrown at me with the following output:

*** buffer overflow detected ***: /usr/bin/neko terminated ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x67257)[0xb760b257] /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x68)[0xb769b7c8] /lib/i386-linux-gnu/libc.so.6(+0xf59b8)[0xb76999b8] /lib/i386-linux-gnu/libc.so.6(+0xf76ba)[0xb769b6ba] /usr/lib/neko/std.ndll(+0x11cb5)[0xb74a9cb5] /usr/lib/neko/std.ndll(+0x11ea4)[0xb74a9ea4] [0xb74de073] /usr/lib/neko/std.ndll(+0x1c0af)[0xb74b40af] /usr/lib/libneko.so.2(+0x1ca30)[0xb7793a30] /usr/lib/i386-linux-gnu/libgc.so.1(GC_inner_start_routine+0x83)[0xb7569b53] [0xb77e12c0] ======= Memory map: ======== 08048000-0804b000 r-xp 00000000 08:01 148670 /usr/bin/neko 0804b000-0804c000 r--p 00002000 08:01 148670 /usr/bin/neko 0804c000-0804d000 rw-p 00003000 08:01 148670 /usr/bin/neko 082b6000-08c5a000 rw-p 00000000 00:00 0 [heap] ... b706a000-b70dd000 r-xp 00000000 08:01 133962 /lib/i386-linux-gnu/libpcre.so.3.13.2 b70dd000-b70de000 r--p 00072000 08:01 133962 /lib/i386-linux-gnu/libpcre.so.3.13.2 b70de000-b70df000 rw-p 00073000 08:01 133962 /lib/i386-linux-gnu/libpcre.so.3.13.2 b70df000-b7449000 rwxp 00000000 00:00 0 b7463000-b746e000 r-xp 00000000 08:01 133932 /lib/i386-linux-gnu/libnss_files-2.23.so b746e000-b746f000 r--p 0000a000 08:01 133932 /lib/i386-linux-gnu/libnss_files-2.23.so b746f000-b7470000 rw-p 0000b000 08:01 133932 /lib/i386-linux-gnu/libnss_files-2.23.so b7470000-b7476000 rw-p 00000000 00:00 0 b7476000-b7492000 r-xp 00000000 08:01 133873 /lib/i386-linux-gnu/libgcc_s.so.1 b7492000-b7493000 rw-p 0001b000 08:01 133873 /lib/i386-linux-gnu/libgcc_s.so.1 b7493000-b7494000 rw-p 00000000 00:00 0 b7494000-b7496000 r-xp 00000000 08:01 148746 /usr/lib/neko/regexp.ndll b7496000-b7497000 r--p 00001000 08:01 148746 /usr/lib/neko/regexp.ndll b7497000-b7498000 rw-p 00002000 08:01 148746 /usr/lib/neko/regexp.ndll b7498000-b74bf000 r-xp 00000000 08:01 148747 /usr/lib/neko/std.ndll b74bf000-b74c2000 r--p 00026000 08:01 148747 /usr/lib/neko/std.ndll b74c2000-b74c8000 rw-p 00029000 08:01 148747 /usr/lib/neko/std.ndll b74c8000-b74f0000 rwxp 00000000 00:00 0 b74f0000-b74f2000 rw-p 00000000 00:00 0 b74f2000-b7545000 r-xp 00000000 08:01 133905 /lib/i386-linux-gnu/libm-2.23.so b7545000-b7546000 r--p 00052000 08:01 133905 /lib/i386-linux-gnu/libm-2.23.so b7546000-b7547000 rw-p 00053000 08:01 133905 /lib/i386-linux-gnu/libm-2.23.so b7547000-b754a000 r-xp 00000000 08:01 133859 /lib/i386-linux-gnu/libdl-2.23.so b754a000-b754b000 r--p 00002000 08:01 133859 /lib/i386-linux-gnu/libdl-2.23.so b754b000-b754c000 rw-p 00003000 08:01 133859 /lib/i386-linux-gnu/libdl-2.23.so b754c000-b757a000 r-xp 00000000 08:01 264429 /usr/lib/i386-linux-gnu/libgc.so.1.0.3 b757a000-b757b000 r--p 0002d000 08:01 264429 /usr/lib/i386-linux-gnu/libgc.so.1.0.3 b757b000-b757c000 rw-p 0002e000 08:01 264429 /usr/lib/i386-linux-gnu/libgc.so.1.0.3 b757c000-b75a4000 rw-p 00000000 00:00 0 b75a4000-b7753000 r-xp 00000000 08:01 133835 /lib/i386-linux-gnu/libc-2.23.so b7753000-b7754000 ---p 001af000 08:01 133835 /lib/i386-linux-gnu/libc-2.23.so b7754000-b7756000 r--p 001af000 08:01 133835 /lib/i386-linux-gnu/libc-2.23.so b7756000-b7757000 rw-p 001b1000 08:01 133835 /lib/i386-linux-gnu/libc-2.23.so b7757000-b775a000 rw-p 00000000 00:00 0 b775a000-b7773000 r-xp 00000000 08:01 133979 /lib/i386-linux-gnu/libpthread-2.23.so b7773000-b7774000 r--p 00018000 08:01 133979 /lib/i386-linux-gnu/libpthread-2.23.so b7774000-b7775000 rw-p 00019000 08:01 133979 /lib/i386-linux-gnu/libpthread-2.23.so b7775000-b7777000 rw-p 00000000 00:00 0 b7777000-b779a000 r-xp 00000000 08:01 174404 /usr/lib/libneko.so.2.1.0 b779a000-b779b000 r--p 00022000 08:01 174404 /usr/lib/libneko.so.2.1.0 b779b000-b779c000 rw-p 00023000 08:01 174404 /usr/lib/libneko.so.2.1.0 b779c000-b77ba000 rwxp 00000000 00:00 0 b77ba000-b77bc000 rw-p 00000000 00:00 0 b77bc000-b77be000 r--p 00000000 00:00 0 [vvar] b77be000-b77bf000 r-xp 00000000 00:00 0 [vdso] b77bf000-b77e1000 r-xp 00000000 08:01 133807 /lib/i386-linux-gnu/ld-2.23.so b77e1000-b77e2000 rw-p 00000000 00:00 0 b77e2000-b77e3000 r--p 00022000 08:01 133807 /lib/i386-linux-gnu/ld-2.23.so b77e3000-b77e4000 rw-p 00023000 08:01 133807 /lib/i386-linux-gnu/ld-2.23.so bfb9e000-bfbbf000 rw-p 00000000 00:00 0 [stack]

Neko target is important to me. First it seems to use less resources, but mostly the build time and debugging is easier on it for me.

[ncannasse]

try running inside gdb and give us backtrace with bt when the crash happens so we can locate which primitive has an issue.

[ncannasse]

PS: if you're doing concurrent access to objects, this is not allowed in Neko

[Horsetopus]

Hi Nicolas, thank you for answering.

So... I have never used gdb. I installed it and tried a few things. Attaching the process seams the easiest way to do things, but as soon as It is attached, the websockets are blocked, unable to communicate. As for launching the neko process throw gdb, I couldn't figure it out. Even turning the .n into an executable with nekotools didn't help. I couldn't find anything on the web, do you have any direction for me?

As for the concurrent access not being allowed in Neko, I use Mutexes. Maybe I missed some spots... but I tipple checked... and also, it should also crash the cpp target, no?

[ncannasse]

@Horsetopus it's hard to tell when multi-thread gets involved, it comes down to whatever CPU instruction gets instructed in which order, etc.

For gdb, if I remember correctly you would do:

> gdb /usr/bin/neko
run myapp.n
(wait for crash)
bt