Process killed by signal

saurabh162

Dear Developers,

In my QT application I am sending command "st" at regular interval (generated using QT timer interrupt after every 1 second) to Beaglebone black (Embedded Hardware) using serial port.

In response to above command I get following output from Hardware.

Value received: 0;70;0;0;0;0

But it has been noticed that after I run above application for some time, then my QT application get crashed automatically and I get following message on Application output window of QT.

"Process killed by signal".

Additionally it has been noticed that just before I get above message from QT, I did not receive anything from serial buffer of BBB in response to my sent command as given below.

Command sent: st

Value received: 0

I have intialized one second QT timer as given below.

timerForBattAndShutDownButton = new QTimer(this);
connect(timerForBattAndShutDownButton, SIGNAL(timeout()),this,SLOT(ShutDownAndBatteryStatus()));
timerForBattAndShutDownButton->start(1000);

Please inform me what can be the reason for "Process killed by signal." message. Kindly inform me if you need any other information from me.

Thank you very much :)

J.Hilk

@saurabh162
please give some more information.

What operating System, what version of qt, and what error message exactly?

Did you try to debug the crash before?

I would suggest not using 5.12 for serial port communication, at least in combination with Windows, I get constant crashes deep inside the win-api, whereas it works fine with 5.11.3

saurabh162

Hello Hilk

Thank you very much for your fast reply.

Following you will get my OS (debian) detail

PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

I am using QT 5.7.1 version.

Actually I do not know how to debug a crash. What I noticed is that everytime my application get crashed after running for 10 minutes.

Thank you !!

J.Hilk

@saurabh162

I'm afraid I won't be much help, my Linux knowledge is very limited - if that's were the problem is.

Why such an old qt-version? Are you limited to that or could you upgrade ?
is it constantly 10 minutes ? Or can it differ vastly ?
What do you use to develop, QtCreator?

saurabh162

Hello Hilk,

following are answers to your questions

Q) Why such an old qt-version? Are you limited to that or could you upgrade ?

Ans) I am using this version of qt because in my embedded hardware I have pre-installed library for qt5.7.1 and it has all components I needed to develop my application.

Q) is it constantly 10 minutes ? Or can it differ vastly ?

Ans) It is crashing after 10 minutes (+- 2 minutes).

Q) What do you use to develop, QtCreator?
Ans ) Yes I use Qt creator 4.4.1

and many thanks for your time

J.Hilk

@saurabh162
alright,

if it's predictably crashing after a certain amount of time, it could be memory leak issue, or some object that gets destroyed and you try to still access it.

Without a proper debug and code shown it's near impossible to say.

Since you're using QtCreator.
Use that to debug your application.
Set your project to debug build and run it. Its the play button with the "bug" on it.
Let it run until it crashes and than you should be able to see exactly where the issue is

You can post the stack trace and/or screenshots if you're having problem at that stage, I'm sure someone can and will help ;-).

saurabh162

Hello Hilk,

Thank you and I will do it and will update you :)

saurabh162

Hello Hilk,

I am testing my application from last 5-6 days but could not able to generate crash again.

One thing I have changed in my code, is ensuring that I handle all bytes generated by Hardware on serial port.

Previously I was missing handling some bytes received by Beaglebone black (BBB) from Hardware. May be above change has solved QT application crash problem. But I am not sure.

But many thanks for your help.

Regards
Saurabh

J.Hilk

hi @saurabh162
if it now doesn't crash, now that you're using a Debug build, make sure you initialize all pointers (with null ptr) and all your variables.

That's 99% of the time why a program crashes in release, but does not in debug mode.

saurabh162

Hello Hilk,

Thank you, yes I will take care of it.

saurabh162

Hello @J-Hilk,

One more question I am sending and receiving data using serial port both from Qt main application and Qt timer slot (triggered at interval of 1 second).

Whether this can also cause crash in application. May be when I try to access Serial port buffer both in Main application and slot of Qt Timer at same time.

Please note: Both my Main application and timer slot is running in same thread.

thank you ..:)

J.Hilk

@saurabh162 said in Process killed by signal:

Hello @J-Hilk,

One more question I am sending and receiving data using serial port both from Qt main application and Qt timer slot (triggered at interval of 1 second).

Whether this can also cause crash in application. May be when I try to access Serial port buffer both in Main application and slot of Qt Timer at same time.

Please note: Both my Main application and timer slot is running in same thread.

Hi,
as long as you don't manually spin the event loop, you're fine. The main application and the timer run in the same thread. That means the Slot evoked by the timer will be executed once the event loop returns, so all functions in your application should have returned as well.
IF you don't manually spin the event loop somewhere.

saurabh162

Hello @J-Hilk

Q) Can you please explain me what do you mean by manually spinning the event loop ?
Whether it means exiting from event loop, for example by calling exit() member function ?

Thank you ..!!

J.Hilk

@saurabh162 I rather not :P it's bad design to do it, and way to many people do it.

But, there are 2 common ways to do it in Qt, I'm going to list them, so you may not use them, if possible.
a) Calling QCoreApplication::processEvents() and b) creating a new QEventLoop and calling start() on it.

If you're doing neither, then should be fine.