Wolfram Schlich wrote:
* Wolfram Schlich <lists@xxxxxxxxxxxxxxxxxxx> [2008-11-13 18:41]:
* Wolfram Schlich <lists@xxxxxxxxxxxxxxxxxxx> [2008-11-13 14:27]:
Here's the answer from the PaX team, for those who might be interested:
* pageexec@xxxxxxxxxxx <pageexec@xxxxxxxxxxx> [2008-11-13 14:18]:
[...]
this is a null function pointer dereference problem on the surface and you'll have to
debug it to get more info. i wonder why nothing shows up in the stack dump however,
maybe there's more corruption here behind the scenes. once you get the coredumps (and
i hope you have debug info saved away ;) we can get a backtrace and other things. also
disable randomization in /proc/sys/... so that results are comparable. best would be
to find a way to directly trigger this crash, then you could have a live gdb session
instead of coredump analysis.
I'll take care of these suggestions now and let you know
about any news.
I've now recompiled conntrack-tools using these CFLAGS:
-march=nocona -O0 -ggdb -DDEBUG
Also, the binaries were not stripped anymore:
/usr/sbin/conntrackd: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped
(I forgot to mention I'm on a 64bit kernel + userland).
My testbed for stress testing is also a 64 bit platform.
I'm now stressing the firewalls with packets.
Damnit, it doesn't break! :)
So it seems that it is only triggered with PaX enabled.
Been stressing the firewall with gigabytes of packets...
Last time it crashed, it hadn't receive a hundred megabytes
of packets at all... *sigh*
Probably you can run conntrackd inside valgrind to see if it complains
about any invalid memory access.
BTW, I'm interested in whatever benchmark results of conntrackd, just
for the record.
--
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
