public inbox for iwd@lists.linux.dev
 help / color / mirror / Atom feed
From: James Prestwood <prestwoj@gmail.com>
To: Richard Acayan <mailingradian@gmail.com>, iwd@lists.linux.dev
Subject: Re: Segmentation fault when taking device for a walk
Date: Fri, 16 Aug 2024 04:53:41 -0700	[thread overview]
Message-ID: <5096b486-d2c1-4a7b-826a-d3e4af9e2eed@gmail.com> (raw)
In-Reply-To: <Zr6cKJePuQd4Dm_n@radian>

Hi Richard,

On 8/15/24 5:24 PM, Richard Acayan wrote:
> Hi,
>
> A segmentation fault occurs in station_start_roam() when the station is
> disconnected from an access point, or in other words, when the station's
> connected_bss is NULL. Usually, this is triggered by a timeout, possibly
> scheduled in response to a weak signal event.
>
> This is occurring on my Pixel 3a running postmarketOS/Alpine Linux, when
> receding from an access point, on iwd 2.19. I have collected 6 coredumps
> of the crash in the span of around 2 weeks and would be willing to use
> GDB if more information is necessary for a patch.
>
> Sample:
>
> 	Program terminated with signal SIGSEGV, Segmentation fault.
> 	#0  0x0000aaaadf2086a0 in station_start_roam (station=0xffff8776ae50) at src/station.c:2880
> 	
> 	warning: 2880	src/station.c: No such file or directory
> 	(gdb) bt
> 	#0  0x0000aaaadf2086a0 in station_start_roam (station=0xffff8776ae50) at src/station.c:2880
> 	#1  0x0000aaaadf28c544 in timeout_callback (fd=<optimized out>, events=<optimized out>,
> 	    user_data=0xffff876b2e20) at ell/timeout.c:68
> 	#2  timeout_callback (fd=<optimized out>, events=<optimized out>, user_data=0xffff876b2e20)
> 	    at ell/timeout.c:57
> 	#3  0x0000aaaadf28b9d0 in l_main_iterate (timeout=<optimized out>) at ell/main.c:461
> 	#4  0x0000aaaadf28bac0 in l_main_run () at ell/main.c:508
> 	#5  l_main_run () at ell/main.c:490
> 	#6  0x0000aaaadf28bce4 in l_main_run_with_signal (
> 	    callback=callback@entry=0xaaaadf1f1110 <signal_handler>, user_data=user_data@entry=0x0)
> 	    at ell/main.c:630
> 	#7  0x0000aaaadf1f0b0c in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:611
> 	(gdb) p station->connected_bss
> 	$1 = (struct scan_bss *) 0x0
>
Its hard to say without any debug logs as well but it appears the 
disconnect never cleared out the timer used for the next roam attempt. I 
did fix a hang due to a disconnect coming in during a roam attempt after 
2.19, but I can't really make heads or tails without debug logs to see 
what happened before/after the disconnect.

Thanks,

James


  reply	other threads:[~2024-08-16 11:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-16  0:24 Segmentation fault when taking device for a walk Richard Acayan
2024-08-16 11:53 ` James Prestwood [this message]
2024-08-19 21:59   ` Richard Acayan
2024-08-20 15:04     ` James Prestwood
2024-08-20 16:00       ` Richard Acayan
2024-08-21 14:27         ` James Prestwood
2024-08-27  0:40           ` Richard Acayan
2024-08-27 11:46             ` James Prestwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5096b486-d2c1-4a7b-826a-d3e4af9e2eed@gmail.com \
    --to=prestwoj@gmail.com \
    --cc=iwd@lists.linux.dev \
    --cc=mailingradian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox