Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#48390 - [wvdial] Assertion `*current_task->stack_magic == 0x123678' failed

Attached to Project: Community Packages
Opened by enrico tognoni (enricotognoni) - Tuesday, 01 March 2016, 19:39 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 02 March 2016, 14:39 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 6
Private No


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


Additional info:
* package version(s)
* config and/or log files etc.

Steps to reproduce:
this is a bit complex, if i use a wire usb 3.0 to connect huaweiE353 in usb 3.0 the huawei is recognized as 12d1:1446 and will not work, if i use direct connection without wire it is recognized but getthe stack_magic error, if i open spacefm (automount option) THEN i plug usb modem, then i get correct recognize and correct connection.
latest wvstream and wvdial installed
This task depends upon

Comment by Andy Cook (dizzib) - Wednesday, 20 April 2016, 08:48 GMT
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.
Comment by Fuki (fukipa) - Tuesday, 10 May 2016, 13:39 GMT
I am also seeing a similar behaviour after a recent full system upgrade.

wvdial: utils/ static int WvTaskMan::yield(int): Assertion `*current_task->stack_magic == 0x123678' failed.
Comment by eimann (eimann) - Tuesday, 10 May 2016, 15:46 GMT
I have the same issue for a while now, sometime it works, sometime doesn't.

--> Modem initialized.
--> Sending: ATDT*99#
--> Waiting for carrier.
wvdial: utils/ 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 (
#1 0x00007fe1e48736da abort (
#2 0x00007fe1e54e8b42 __assert_fail (
#3 0x00007fe1e54c18c2 _ZN9WvTaskMan5yieldEi (
#4 0x00007fe1e54c1e04 _ZN9WvTaskMan7do_taskEv (
#5 0x00007fe1e54c2015 _ZN9WvTaskMan12_stackmasterEv (
#6 0x00007fe1e54c20b3 _ZN9WvTaskMan11stackmasterEv (
#7 0x00007fe1e54bac37 _ZN8WvStringaSERK12WvFastString (
#8 0x00007fe1e54c1788 _ZN9WvTaskMan3runER6WvTaski (
#9 0x00007fe1e54b617a _ZN6WvCont5_callEPNS_4DataE (
#10 0x00007fe1e54b6329 _ZN6WvContclEPv (
#11 0x00007fe1e54cce9c _ZNSt3tr117_Function_handlerIFPvS1_E6WvContE9_M_invokeERKNS_9_Any_dataES1_ (
#12 0x00007fe1e54c8493 _ZN8WvStream8callbackEv (
#13 0x0000000000406b79 n/a (wvdial)
#14 0x00007fe1e485f741 __libc_start_main (
#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 (
#1 0x00007f547323b6da abort (
#2 0x00007f5473eb0b42 __assert_fail (
#3 0x00007f5473e898c2 _ZN9WvTaskMan5yieldEi (
#4 0x00007f5473e89e04 _ZN9WvTaskMan7do_taskEv (
#5 0x00007f5473e8a015 _ZN9WvTaskMan12_stackmasterEv (
#6 0x00007f5473e8a0b3 _ZN9WvTaskMan11stackmasterEv (
#7 0x000000000000000e n/a (n/a)
Comment by Soumik Rakshit (sln) - Thursday, 12 May 2016, 23:47 GMT
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.
Comment by Fuki (fukipa) - Thursday, 26 May 2016, 10:33 GMT
Is there a way to update the Severity level to high as the program itself is not working ?
Comment by Andy Cook (dizzib) - Friday, 03 June 2016, 15:11 GMT
Possibly related, there is a known regression in usb_modeswitch:

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.
Comment by aka wakka (broetchen2) - Wednesday, 08 June 2016, 18:57 GMT
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.
Comment by stas (nott) - Friday, 17 June 2016, 10:25 GMT Comment by stas (nott) - Friday, 17 June 2016, 10:30 GMT
Disregard my last comment: it's from 2012 and it's been solved in Arch long ago.
Comment by CrazyT (CrazyT) - Saturday, 16 July 2016, 10:00 GMT
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 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:

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.

Comment by smekkleysa (smekkleysa) - Sunday, 17 July 2016, 10:19 GMT
Thank you for the patch, but it did not work in my envinronment.
Comment by CrazyT (CrazyT) - Sunday, 17 July 2016, 11:13 GMT
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.
Comment by smekkleysa (smekkleysa) - Sunday, 17 July 2016, 11:16 GMT
After increasing the "total" value to 2048, it worked.

PPPD lcp times out, but it's due to my misconfiguration of PPPD I guess.
Comment by Max Rees (sickbike) - Saturday, 06 August 2016, 04:29 GMT
Can also confirm that changing the "total" value to 2048 fixes this issue on my end.
Comment by Soumik Rakshit (sln) - Monday, 08 August 2016, 23:06 GMT
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.
Comment by Richard Stellingwerff (remenic) - Friday, 14 October 2016, 11:21 GMT
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.
Comment by Reynaldo (gilcu3) - Tuesday, 18 October 2016, 12:36 GMT
@remenic this is what I did when finally realized wvdial wasn't going to be fixed soon enough..
Comment by charlie wolf (usuallycharlie) - Sunday, 23 April 2017, 19:37 GMT
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.
Comment by Ivy Foster (escondida) - Thursday, 10 October 2019, 04:34 GMT
Is this problem still present in current versions?