Arch Linux

I'm seeing similar behaviour after a recent full system upgrade. After replugging the modem into the usb (2.0) port, there's only a 33% chance of usb_modeswitch successfully recognising the modem as 12d1:1506 within 5 seconds. Then it's a lottery if the assertion error occurs or not.

I am also seeing a similar behaviour after a recent full system upgrade.

wvdial: utils/wvtask.cc:304: static int WvTaskMan::yield(int): Assertion `*current_task->stack_magic == 0x123678' failed.

I have the same issue for a while now, sometime it works, sometime doesn't.

--> Modem initialized.
--> Sending: ATDT*99#
--> Waiting for carrier.
ATDT*99#
wvdial: utils/wvtask.cc:304: static int WvTaskMan::yield(int): Assertion `*current_task->stack_magic == WVTASK_MAGIC' failed.
Aborted (core dumped)

May 10 17:40:35 hostname systemd[1]: Started Process Core Dump (PID 1522/UID 0).
May 10 17:40:35 hostname systemd-coredump[1525]: Process 1521 (wvdial) of user 0 dumped core.

Stack trace of thread 1521:
#0 0x00007fe1e4872295 raise (libc.so.6)
#1 0x00007fe1e48736da abort (libc.so.6)
#2 0x00007fe1e54e8b42 __assert_fail (libwvbase.so.4.6)
#3 0x00007fe1e54c18c2 _ZN9WvTaskMan5yieldEi (libwvbase.so.4.6)
#4 0x00007fe1e54c1e04 _ZN9WvTaskMan7do_taskEv (libwvbase.so.4.6)
#5 0x00007fe1e54c2015 _ZN9WvTaskMan12_stackmasterEv (libwvbase.so.4.6)
#6 0x00007fe1e54c20b3 _ZN9WvTaskMan11stackmasterEv (libwvbase.so.4.6)
#7 0x00007fe1e54bac37 _ZN8WvStringaSERK12WvFastString (libwvbase.so.4.6)
#8 0x00007fe1e54c1788 _ZN9WvTaskMan3runER6WvTaski (libwvbase.so.4.6)
#9 0x00007fe1e54b617a _ZN6WvCont5_callEPNS_4DataE (libwvbase.so.4.6)
#10 0x00007fe1e54b6329 _ZN6WvContclEPv (libwvbase.so.4.6)
#11 0x00007fe1e54cce9c _ZNSt3tr117_Function_handlerIFPvS1_E6WvContE9_M_invokeERKNS_9_Any_dataES1_ (libwvbase.so.4.6)
#12 0x00007fe1e54c8493 _ZN8WvStream8callbackEv (libwvbase.so.4.6)
#13 0x0000000000406b79 n/a (wvdial)
#14 0x00007fe1e485f741 __libc_start_main (libc.so.6)
#15 0x0000000000405c39 n/a (wvdial)
May 10 17:41:36 hostname systemd[1]: Started Process Core Dump (PID 1559/UID 0).
May 10 17:41:36 hostname systemd-coredump[1560]: Process 1557 (wvdial) of user 0 dumped core.

Stack trace of thread 1557:
#0 0x00007f547323a295 raise (libc.so.6)
#1 0x00007f547323b6da abort (libc.so.6)
#2 0x00007f5473eb0b42 __assert_fail (libwvbase.so.4.6)
#3 0x00007f5473e898c2 _ZN9WvTaskMan5yieldEi (libwvbase.so.4.6)
#4 0x00007f5473e89e04 _ZN9WvTaskMan7do_taskEv (libwvbase.so.4.6)
#5 0x00007f5473e8a015 _ZN9WvTaskMan12_stackmasterEv (libwvbase.so.4.6)
#6 0x00007f5473e8a0b3 _ZN9WvTaskMan11stackmasterEv (libwvbase.so.4.6)
#7 0x000000000000000e n/a (n/a)

Same issue as above. Had to try a few times before it would succeed without raising the assertion, but with the kernel upgrade it doesn't succeed at all no matter how many times I re-run the command.

Is there a way to update the Severity level to high as the program itself is not working ?

Possibly related, there is a known regression in usb_modeswitch: http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=2&t=2329&sid=89876376787f8e50416d97d2a62d637a

EDIT: after a full system upgrade with fixed usb_modeswitch 2.4.0-2, usb_modeswitch now works consistently. However wvdial always fails with the assertion error. In the end I had to abandon wvdial in favour of systemd with pppd.

I have the same issue with the E160, also after replugging a hundred times. Is there any workaround?? I really need to get my surfstick work again! Downgrading wvdial and wvstream don't solve this issue.

A workaround is described here: https://bugzilla.redhat.com/show_bug.cgi?id=812651#c14

Disregard my last comment: it's from 2012 and it's been solved in Arch long ago.

Its a bit weird, on my linux-machine it had an overflow, but inside docker in windows it behaved differently.

Basically in linux the stack_magic was overwritten by a "trampoline" function before makecontext was called.
(i believe the file was called "dl-trampoline.h" - can't find that file on my docker in windows btw.)
Beside some other changes I just changed the file wvtask.cc and modified the line "total = 1024" to "total = 1026".
After that it was working without the "stack_magic"-error.

I added an archive with the modified files.
I forgot to add the unchanged files, you still need to fetch the package from svn and copy the fix over it:
https://www.archlinux.org/svn/

Keep in mind that it is just a workaround atm.
Wich means i do not even know if 1026 is enough, or if it might crash later or some other unexpected behaviour could happen.

Thank you for the patch, but it did not work in my envinronment.

Are you getting the same exception,still?

I'm remembering that i also need to change the wvdial.conf.
Without a change of the "PPPD Path" it points to the wrong pppd path.

After increasing the "total" value to 2048, it worked.

PPPD lcp times out, but it's due to my misconfiguration of PPPD I guess.

Can also confirm that changing the "total" value to 2048 fixes this issue on my end.

I can confirm too! Changed it to 2048 (and applied the patch to add the static_cast<bool>s, or it wouldn't compile) and it finally works.

Andy Cook (dizzib), any chance you could share how to replace wvdial with systemd? If possible, I would like to abandon wvdial as well, but I was unable to find instruction on how to do this.

@remenic this is what I did when finally realized wvdial wasn't going to be fixed soon enough..

Here is an actual patch against `community` SVN to apply the 1024=>2048 fix mentioned by smekkleysa, sickbike and sln. I can confirm this fix works for me as well.

Is this problem still present in current versions?