Ubuntu
kismet package

kismet crashed with SIGSEGV in feof()

Bug #179233 reported by zdzichu
178
This bug affects 22 people
Affects Status Importance Assigned to Milestone
kismet (Debian)
Fix Released
Undecided
Unassigned
kismet (Ubuntu)
Invalid
Medium
Unassigned
Nominated for Jaunty by Nausea Bond

Bug Description

Binary package hint: kismet

Crashed when exiting.

ProblemType: Crash
Architecture: i386
Date: Fri Dec 28 16:44:33 2007
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/kismet
NonfreeKernelModules: cdrom
Package: kismet 2007-10-R1-2
PackageArchitecture: i386
ProcCmdline: kismet
ProcCwd: /var/log
ProcEnviron:
 SHELL=/bin/bash
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 LANG=pl_PL.UTF-8
 LANGUAGE=pl_PL:pl:en_GB:en
Signal: 11
SourcePackage: kismet
Stacktrace:
 #0 0xb7cbb9e1 in feof () from /lib/tls/i686/cmov/libc.so.6
 #1 0x08049224 in ?? ()
 #2 0x08049cd6 in ?? ()
 #3 0xb7c70450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
 #4 0x08048e81 in ?? ()
StacktraceTop:
 feof () from /lib/tls/i686/cmov/libc.so.6
 ?? ()
 ?? ()
 __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
 ?? ()
Title: kismet crashed with SIGSEGV in feof()
Uname: Linux sandworm 2.6.24-2-generic #1 SMP Thu Dec 20 17:36:12 GMT 2007 i686 GNU/Linux
UserGroups:
SegvAnalysis:
 Segfault happened at: 0xb7cbb9e1 <feof+33>: cmp %edi,0x8(%edx)
 PC (0xb7cbb9e1) ok
 source "%edi" ok
 destination "0x8(%edx)" (0x2064656d) not located in a known VMA region (needed writable region)!
SegvReason: writing unknown VMA

See original description
Revision history for this message
zdzichu (zdzichu-gmail) wrote :
Revision history for this message
Apport retracing service (apport) wrote : Symbolic stack trace

StacktraceTop:feof () from /lib/tls/i686/cmov/libc.so.6
reap (sig=0) at kismet_wrapper.cc:81
main (argc=1, argv=0xbff531a4, envp=) at kismet_wrapper.cc:311
__libc_start_main () from /lib/tls/i686/cmov/libc.so.6
_start ()

Revision history for this message
Apport retracing service (apport) wrote : Symbolic threaded stack trace
Revision history for this message
Apport retracing service (apport) wrote : Stack trace with source code
Changed in kismet:
importance: Undecided → Medium
Revision history for this message
Laurent Bigonville (bigon) wrote :

same problem here

Changed in kismet:
status: New → Confirmed
Revision history for this message
Jim Qode (jimqode) wrote :

same here with hardy alpha 6

Revision history for this message
Barteq (barteqpl) wrote :

Same problem here.
Latest hardy release - 2.6.24-12-generic + iwl4965 (1.2.0)

kismet 2007-10-R1-2build1

Error occurs after quiting kismet-ui (or kismet alone). Quits with coredump and network card stays in monitor mode. Sometimes it becames a zombie card without ability to change mode or rrmod driver. It might be a driver issue too. Please check it with newest iwl drivers and check bug #183928

Revision history for this message
Jisakiel (jisakiel) wrote :

Same problem here. Using both iwl3945 and ipwraw-ng with networkmanager active and associated before launching kismet, and as well using an ethernet network.

With iwl3945 card remains "stuck" in monitor mode and I have to unload / reload the module to be able to change it to managed mode.

Using hardy

Revision history for this message
karlrt (karlrt) wrote :

same problem here, kismet-ui crashes everytime i quit it, use the iwl6945, newest hardy amd64

Revision history for this message
Miloš Mandarić (mandzo18) wrote :

same problem. I am using Intrepid ubuntu beta b43.

Revision history for this message
wulf solter (wulfsolter) wrote :

interpid ibex alpha 6 with latest iwl3945 and ipwraw

Revision history for this message
kevh100 (kev-kphonline) wrote :

same prob with ath5k driver on my Acer Aspire One ( AR242x 802.11abg Wireless PCI Express Adapter (rev 01))

to get the card out of monitor mode just do this:
rmmod ath5k
modprobe ath5k

then it works fine :)

Kev

Revision history for this message
John Clarke (jrc61) wrote :

Similar crash here. Up-to-date Intrepid, kismet-2008-05-R1-4, iwl3945 wireless. Leaves wireless networking broken.

To get wireless networking working again, I don't need to unload iwl3945, disabling then re-enabling wireless networking (with nm-applet) does the job.

Revision history for this message
Hilario J. Montoliu (hjmf) (hmontoliu) wrote :

The same problem is still present in karmic; see bug #430219

Kees Cook (kees)
description: updated
Bob Bib (bobbib)
tags: added: hardy i386
Nick Andrik (andrikos)
no longer affects: kismetwireless
Bug Watch Updater (bug-watch-updater)
Changed in kismet (Debian):
status: Unknown → New
Revision history for this message
Nick Andrik (andrikos) wrote :

Current kismet version is 2013.03.R1b-1 .

I cannot reproduce this bug in the most current version.
Could anyone that had confirmed the initial bug report also test it themselves?
Since there has been extensive development from the time the bug was reported (6 years ago), there is serious probability that it is already fixed.

Thanks

Changed in kismet (Ubuntu):
status: Confirmed → Incomplete
Bug Watch Updater (bug-watch-updater)
Changed in kismet (Debian):
status: New → Incomplete
Revision history for this message
dino99 (9d9) wrote :

fixed upstream

Changed in kismet (Debian):
importance: Unknown → Undecided
status: Incomplete → New
status: New → Fix Released
Changed in kismet (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.