traffic daemon process [7593] received signal 'Segmentation fault'

[kayser@…]

Hello This his happening with current trunk Gentoo 2008.0 x86 kernel 2.6.22-vs2.2.0.6-gentoo AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux FS is reiserfs. I tried to scp another build i did on my test server (that is working without any problem) and the same problem occurs traffic daemon process received signal 'Segmentation fault' So there is no graph on web-interface No more information while debug is on.

[ftx]

thanks a lot for your report, we will investigate this problem

[kayser@…]

I spent some time to investigate on it today, i didn't find how it's happening. strace looks correct. Tried on my test platform (dual xeon) it works very well without any problem Tried on my production platform (amd 3000+) over a 32bits distribution, the traffic daemon just die. Without telling me anything even DEBUG=0 and openvcpd -v. I used the same method for compilation on both, no error reported while configure and make. By the way if you need some outputs of strace or whatever, juste let me know. Thank you very much, your work is great !

Replying to ftx:

thanks a lot for your report, we will investigate this problem

[kayser@…]

So i tried gdb here is an output. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set follow-fork-mode child (gdb) break handle_packets Breakpoint 1 at 0x8052048: file src/logtraffic.c, line 60. (gdb) run Starting program: /bin/openvcpd [Thread debugging using libthread_db enabled] [New Thread 0xb7b816c0 (LWP 12322)] Breakpoint 1 at 0x8052030: file src/logtraffic.c, line 60.

Program exited with code 01.

So gdb stills handle very badly threads debug.

Gonna try with efence ...

[scythale@…]

Hi,

I've just helped Kayser to investigate the problem and the problem lies in the kernelmodule_loaded() function in misc.c : you don't check the return value of fopen() and on kernel without module support, the /proc/modules file doesn't exist. You should ALWAYS check return values from the functions you call (well, except from some functions like printf()). This results in a call to fscanf() with a NULL pointer, which isn't good for the system :). You should try to find another way to check if the feature you're requesting is present in case /proc/modules doesn't exist. Also, in traffic.c you call modprobe via system(), which is a bad thing : always give the complete path of the application, otherwise you could introduce vulnerabilities.

Have a nice day.

-- scythale

[kayser@…]

Replying to scythale@gmail.com: You should try to find another way to check if the feature you're requesting is present in case /proc/modules doesn't exist.

We won't post the .diff we made to let it works correctly due to the nature of the problem. It's just a workaround. My kernel is compiled with everything on it. But as scythale said you've to find a way to check if theses modules are built-in in case of /proc/modules doesn't exist.

If someone is in the same case of me, monolitic kernel and all dependancies built-in (ip_tables/ifb), feel free to ask me the patch by email.

Best regards

[ftx]

thanks a lot for the detailed report fixed in r632