Kismet Wireless

Kismet Forums


Posted by:fisted
Subject:kismet_server - segfault in libnl prior to main()
Date:06:06:50 21/11/2012

> > Hey,
> >
> > i also posted this to the libnl mailing list, since i assume it's libnl's fault, but since i don't know exactly, i thought i should post here, too:
> >
> > it's about kismet_server, latest svn version as of yesterday (2012/11/20)
> >
> > here's the post:
> > In particular this is about kismet, a program using libnl, which segfaults right after launch, before even main() is called.
> > It looks like libnl is responsible, here's what i did and some information:
> Wow, that's pretty special...
> No, I've never seen this happen - I'm not even sure what might be going on.
> Can you compile libnl w/ full debug symbols, and then run the both of them through valgrind or something? Might give more info.
> That it blows up before main either means that something in dlinit in libnl (or your linker in general) is totally fried, or that it's corrupting the stack so completely that it doesn't know where it is anymore.
> Try valgrind. Sometimes that can reveal things gdb can't.

Hi, thanks for the quick reply.

Unfortunately valgrind gave no further information, here's the output:
# valgrind ./kismet_server
==21222== Memcheck, a memory error detector
==21222== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==21222== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==21222== Command: ./kismet_server
==21222== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==21222== Bad permissions for mapped region at address 0x6D308EC
==21222== at 0x59E0ED5: genl_register (mngt.c:260)
==21222== by 0x400E72E: call_init (in /lib64/
==21222== by 0x400E81D: _dl_init (in /lib64/
==21222== by 0x4000BD9: ??? (in /lib64/
==21222== HEAP SUMMARY:
==21222== in use at exit: 349 bytes in 18 blocks
==21222== total heap usage: 19 allocs, 1 frees, 917 bytes allocated
==21222== LEAK SUMMARY:
==21222== definitely lost: 0 bytes in 0 blocks
==21222== indirectly lost: 0 bytes in 0 blocks
==21222== possibly lost: 349 bytes in 18 blocks
==21222== still reachable: 0 bytes in 0 blocks
==21222== suppressed: 0 bytes in 0 blocks
==21222== Rerun with --leak-check=full to see details of leaked memory
==21222== For counts of detected and suppressed errors, rerun with: -v
==21222== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Segmentation fault

since the line in question is as simple as 'ops->co_genl->o_cache_ops = ops;', with no NULL pointers involved here (checked that), and the fault is 'bad permissions', i guess it's indeed out of kismet's scope

i will try downgrading libnl until it works ;)

Reply to this message