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
next prev parent 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