ndpiReader ends up with segmentation fault

[vel21ripn]

ndpiReader ends up with segmentation fault

[vel21ripn]

I do not see sigfault in strace
It would be interesting to see "gdb ndpiReader core".

[clebig]

The testing environment is an up to date Debian 9 running in a KVM

Starting program: /root/nDPI/example/ndpiReader ./ndpiReader -i /tmp/test.pcap
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

---

• NOTE: This is demo app to show some nDPI features.
• In this demo we have implemented only some basic features
• just to show you what you can do with the library. Feel
• free to extend it and send us the patches for inclusion

---

Using nDPI (2.6.0-1422-2586e77) [1 thread(s)]

Program received signal SIGSEGV, Segmentation fault.
__memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:294
294 ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0 __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:294
#1 0x00007ffff6db0e54 in _IO_new_file_xsputn (f=0x555555ab91d0, data=0x55555559a237, n=13) at fileops.c:1327
#2 0x00007ffff6d84e36 in _IO_vfprintf_internal (s=0x555555ab91d0, format=0x55555559a237 "Num threads: %d\n", ap=ap@entry=0x7fffffffe8e8) at vfprintf.c:1320
#3 0x00007ffff6d8d187 in __fprintf (stream=, format=) at fprintf.c:32
#4 0x0000555555565d0b in test_lib () at ndpiReader.c:2636
#5 0x000055555555fe2a in main (argc=, argv=) at ndpiReader.c:3350
(gdb) i r
rax 0x2d2d0a5d29732871 3255269500902385777
rbx 0x555555ab91d0 93824997888464
rcx 0x203a736461657268 2322295432830874216
rdx 0xd 13
rsi 0x65726874206d754e 7310019993145275726
rdi 0x2d2d0a5d29732864 3255269500902385764
rbp 0xd 0xd
rsp 0x7fffffffe338 0x7fffffffe338
r8 0x7ffff7feb740 140737354053440
r9 0x0 0
r10 0x8 8
r11 0x246 582
r12 0x55555559a237 93824992518711
r13 0xd 13
r14 0x0 0
r15 0xd 13
rip 0x7ffff6dc1f96 0x7ffff6dc1f96 <__memmove_sse2_unaligned_erms+102>
eflags 0x10206 [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0

[vel21ripn]

IMHO The cause of the error is not in nDPI.
I'm pretty sure that running ndpiReader on a physical host, and not on a guest, will not lead to sigsegv.
And what processor is emulated in the guest system?
Is "grep sse2 /proc/cpuinfo" empty in the guest system?

[clebig]

SSE2 is visible in the guest's CPUs.

processor : 23
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Common KVM processor
stepping : 1
microcode : 0x1
cpu MHz : 2933.436
cache size : 16384 KB
physical id : 3
siblings : 6
core id : 5
cpu cores : 6
apicid : 29
initial apicid : 29
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology pni cx16 x2apic hypervisor lahf_lm kaiser
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5866.87
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:

[vel21ripn]

I run a virtual system on qemu-2.11/kvm and ndpiReader works without sigsegv.
I can not test the configuration with 24 processors. I have only 8 cores :(
Try running your ndpiReader on any other 64-bit platform.

[clebig]

Would you want an access to this VM ?

I'll try to present only 8 cores to it and try again.

[clebig]

When I compile ndpiReader from ntop/nDPI branches dev, 2.4-stable and 2.6-stable, I don't get sigsegv.
Here my results for ndpiReader sigsevs
ntop/nDPI dev branch : OK
ntop/nDPI 2.4-stable branch : OK
ntop/nDPI 2-8-stable branch : OK

ndpi netfilter-2.2 branch : OK
ndpi netfilter-2.6 branch : NOT OK -> Using nDPI (2.6.0-1430-bee714f) [1 thread(s)]
Segmentation fault
ndpi flow_info : NOT OK -> Using nDPI (2.8.0-1491-c8ee735) [1 thread(s)]
Segmentation fault

[clebig]

I see here b6f4e84 that you already had sigsegv problems before. Could it be related to it ?

[vel21ripn]

Yes! This minor fix was lost upon upgrading to 2.6.