Some issues with ussd-gui

[morfikov]

While testing ussd-gui I've come across some weird behavior.

1 Is there a way to cancel an action after sending a USSD code? Let's say we've set timeout to 300s, how to cancel the action? 2 Is there a way to terminate ussd-gui while sending a code? I've tried to cancel/close the window, but without a success. 3 Is there a way to implement comments in the ussd-gui config file? For now some lines starting with # are removed, the others get rewritten to the following after sending a USSD code:

%23%20timeout=20
%23timeout=30

4 When exiting by closing the ussd-gui window, I often get segfault:

kernel: ussd-gui[73403] segfault at 7fcff2880e18 ip 00007fcff2880e18 sp 00007fffb8f432c8 error 15 in libQt5Core.so.5.5.1[7fcff2879000+c000]

5 Is there a way to fix the connect/disconnect button. For now it's almost impossible to simply disconnect because it reconnects right away. I think it catches the previous mouse click, and that's why it reconnects after clicking disconnect.

[mhogomchungu]

First and second points are related so i will answer them together. Libgammu can terminate any ongoing operation but the internal backend currently can not as all access to the device are done in a background thread and there is currently no way to terminate the thread. My current implementation of libgammu just ignores the request but doesnt cancel it. Both of these backends currently do not properly support cancelling a request and quitting the application while operations are still pending will most likely lead to a crash.

I have not experienced long delays and have not looked closely at how to properly cancel long time taking operations and for now,i think the most straight forward answer is,"its not possible".

Implementing comments in the config file? I do not know,will do it only if QSettings[1] supports them.

I have not seen any segfault in Qt4,will start using it with Qt5 to test. Can you update to the latest git and see if the segfaults are still there? I made a few changes hours ago and they might have solved the problem.

I can disable the connect/disconnect button temporarily to try to fix the double click you are getting.A workaround exists and that is to click the button through "alt+d" key combo. [1] http://doc.qt.io/qt-4.8/qsettings.html

[morfikov]

I just updated to the last commit.

I got new errors:

kernel: traps: Task::Thread[81300] general protection ip:7fcb041a0bc8 sp:7fcaec15bdd8 error:0 in libc-2.22.so[7fcb04076000+19a000]
kernel: Task::Thread[81965] segfault at 7f91dd03a014 ip 00007f91f6c498df sp 00007f91de05bde0 error 4 in libQt5Core.so.5.5.1[7f91f6b9f000+4c5000]
kernel: Task::Thread[85099] segfault at 4 ip 00007f14ef1138df sp 00007f14d652ade0 error 4 in libQt5Core.so.5.5.1[7f14ef069000+4c5000]

It looks like the errors show up when you do the following procedure:

open ussd-gui click "connect" button send a USSD code by clicking the "send" button click the "quit" button or close the window by clicking X.

And here in the syslog you get one of the errors above. I think I know why the errors appear. They probably show up because of building a debian package with DEB_BUILD_MAINT_OPTIONS = hardening=+all. I''ll check without it.

It could be a wrong interface. For instance. In the case of E3372s modem, I have 2 interfaces (for short 0 and 1). For some reason ussd-gui stopped talking with this device via the 0 interface. It simply returns no answers (waits for timeout), but still connects. It works fine with the 1 interface though. When I set the 0 interface in the config file, I get the errors, whereas 1 it looks good.

[morfikov]

Yes, that was the cause of the errors.

[mhogomchungu]

The way it currently works is as follows:

Thread 1 powers the GUI and there is no problem with this thread.

The following happens when you click "send":

1. Thread 2 is created on demand and blocks waiting for data to read from the device.
2. Thread 3 is then created on demand and ussd command is sent to the device through this thread.
3. Thread 3 quits after it has sent its data.
4. Thread 2 quits after it has received data.

Qt generally does not like threads to still be running when the application closes and crashes usually occur when it happens.

It should not be possible to quit the application while an operation is still pending because a Qt's thread will still be in use. I am currently working on properly cancelling an operation and hopefully,your crashes will go away.

Currently,hitting a timeout will most likely also cause a crash on exit for the same reason,a hanged thread will be around while the program is exiting.

[morfikov]

I just tested the newest commit. The errors are gone for now even with DEB_BUILD_MAINT_OPTIONS = hardening=+all . The ussd-gui binary looks like this now:

$ hardening-check /usr/bin/ussd-gui
/usr/bin/ussd-gui:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: unknown, no protectable libc functions used
 Read-only relocations: yes
 Immediate binding: yes

I have no idea what Fortify Source functions: unknown, no protectable libc functions used means and how to fix that.

[morfikov]

I know what's going on with the connect/disconnect button. Try to click on disconnect, and while pressing the mouse button move the mouse. It will connect as soon as the mouse moves.

[morfikov]

The connect/disconnect button bug also was fixed. So one bug less.

[morfikov]

It looks like the button improvement gives now lots of:

Apr 29 10:22:51 morfikownia kernel: ussd-gui[12601] segfault at 6 ip 00007f8fa9841dc4 sp 00007ffdf747f860 error 4 in libQt5Core.so.5.5.1[7f8fa9708000+4c5000]
Apr 29 10:23:31 morfikownia kernel: ussd-gui[12940] segfault at 6 ip 00007fb726ccedc4 sp 00007fff8ee88f50 error 4 in libQt5Core.so.5.5.1[7fb726b95000+4c5000]
Apr 29 10:24:03 morfikownia kernel: ussd-gui[13288] segfault at 6 ip 00007f602fe4ddc4 sp 00007fff9d3bc090 error 4 in libQt5Core.so.5.5.1[7f602fd14000+4c5000]
Apr 29 10:27:42 morfikownia kernel: ussd-gui[14032] segfault at 0 ip           (null) sp 00007ffc55f6c108 error 14 in ussd-gui[56246b6aa000+34000]

When I connect, everything is fine. When I send the very first USSD code, everything is ok. But then when I point to a button, click it and then move my mouse, I get a segfault. Of course with hardening, but I didn't notice such behavior in previous versions.

[mhogomchungu]

I didnt fully get what you just said,

Are you saying that:

1. You can connect normally and send USSD codes just fine.
2. When you click the "disconnect" button and then move your mouse while still clicking it,it segfaults? What happens when you click the button through "alt+d" key combo? Do you still get segfaults/problems?
3. Does your mouse have a double clicking problem?
4. Why do you click the button,hold on to the click and then move your mouse? That seems like a strange thing to do.

[morfikov]

No, my mouse works just fine. I experience the problem only with ussd-gui and not all the time, just after sending the first code. I know that normally you don't click and move your mouse. But sometimes you do little movements and they give segfault when the mouse button is pressed,

[mhogomchungu]

Does the crash happen when you click any button or when you click a specific one? If specific one,which one?

What desktop environment are you using?

[morfikov]

It looks like only the send button is affected. I tried all but, only send gives segfault, but this happens only after sending the very first code. When I do the same move before sending the code, there's no crash.

I'm using standalone openbox.

[mhogomchungu]

Will try to disable the "send" button as soon as the button is clicked and hopefully the problem ill go away.

Have you tried to check sms using the internal backend? Does it still not work? It will be better if you answer the question the other bug report thread.

[morfikov]

I know what's wrong with SMS. It receives only when there's an SMS. When it's empty it gives the error Status: ERROR 7:

[mhogomchungu]

Just made a commit that will disable the send button right after its clicked.Hopefully,this will solve the problem if the problem is due to the button being clicked twice when you dont release it soon enough;

[mhogomchungu]

Just made another commit that will say there are no sms when none were found.

[morfikov]

I will test that in a minute.

[morfikov]

The segfault still occurs.

[morfikov]

This segfault concerns only codes that you have to response to

[mhogomchungu]

Do they still occur when you press the button through "alt+s" key combo?

[morfikov]

Actually you have to use a mouse so the segfault would show up. Because it depends only on moving the mouse when the left mouse button is pressed. When you don't move the mouse, there's no segfault at all.

[morfikov]

I know where's the problem. When you receive a reply to the USSD code, the input field is empty. When you try to send a code, then you get segfault. But if you type something, there's no segfault

[mhogomchungu]

Yep,could reproduce it now and i already pushed a commit that fixes the problem.

Hope the problem is now fixed for good :-)

[morfikov]

Yep, the issue is fixed now.

So is there something that can be done in the case of closing the app's window while sending a USSD code? And what about the comments in the config file?

[mhogomchungu]

QSettings does not allow comments and hence its not possible to ussd-gui to support comments in its config file.

Code for cancelling ongoing operation is already in place, all that is left is exposing it to the GUI and testing it. Will get back to you on this one when i have something worth testing.

You should set timeout to about 15 seconds as anything that takes more time will most likely not going to succeed.

[mhogomchungu]

The connect/disconnect button remains active when sending a request making it possible to cancel it by disconnecting.

I think this concludes this bug report and hence i am closing it.

Feel free to respond if i have missed anything.