can anybody suggest the way to find hang and Crash issue in auto start based qt application ?

JonB

@Qt-embedded-developer said in can anybody suggest the way to find hang and Crash issue in auto start based qt application ?:

As i have put debug log but it stops where that function run 1000 time right for same passed value.
so log also does not help me where the issue is ?

What logging stops at 1000 times? If, for whatever reason, you need more than that just write your own logger.

Or, for a SIGSEGV get whatever Linux you are using to produce a core dump file and debug from that (e.g. with gdb) after the event. Make sure your code is compiled for debug.

JoeCFD

@Qt-embedded-developer On Linux, try to make a core dump. Then debug the core file.

Qt embedded developer

@JoeCFD i have generated core dump file.

but i can not able to understand this file so that i can not able to find what cause the crash.

my core dump file is show below content

7fa98d09a000-7fa98d09c000 r--p 00000000 b3:02 268509                     /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
 7fa98d09c000-7fa98d0c6000 r-xp 00002000 b3:02 268509                     /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
 7fa98d0c6000-7fa98d0d1000 r--p 0002c000 b3:02 268509                     /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
 7fa98d0d1000-7fa98d0d2000 r--s 00000000 b3:02 800865                     /home/onyx/.cache/myApp/qmlcache/00cde4e6211f47f6abbba91a3b1b55ebb830b1ca.qmlc
 7fa98d0d2000-7fa98d0d4000 r--p 00037000 b3:02 268509                     /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
 7fa98d0d4000-7fa98d0d6000 rw-p 00039000 b3:02 268509                     /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
 7ffd105c6000-7ffd105e8000 rw-p 00000000 00:00 0                          [stack]
 7ffd105f0000-7ffd105f4000 r--p 00000000 00:00 0                          [vvar]
 7ffd105f4000-7ffd105f6000 r-xp 00000000 00:00 0                          [vdso]
 ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
ProcStatus:
 Name:	myApp
 Umask:	0002
 State:	S (sleeping)
 Tgid:	1550
 Ngid:	0
 Pid:	1550
 PPid:	1043
 TracerPid:	0
 Uid:	1000	1000	1000	1000
 Gid:	1000	1000	1000	1000
 FDSize:	128
 Groups:	4 20 24 27 30 46 122 134 135 1000 
 NStgid:	1550
 NSpid:	1550
 NSpgid:	938
 NSsid:	612
 VmPeak:	 3199520 kB
 VmSize:	 3187520 kB
 VmLck:	       0 kB
 VmPin:	       0 kB
 VmHWM:	  212608 kB
 VmRSS:	  208616 kB
 RssAnon:	   97396 kB
 RssFile:	  111132 kB
 RssShmem:	      88 kB
 VmData:	  426548 kB
 VmStk:	     136 kB
 VmExe:	    4760 kB
 VmLib:	  195892 kB
 VmPTE:	    1432 kB
 VmSwap:	       0 kB
 HugetlbPages:	       0 kB
 CoreDumping:	1
 THP_enabled:	1
 Threads:	37
 SigQ:	0/14764
 SigPnd:	0000000000000000
 ShdPnd:	0000000000000000
 SigBlk:	0000000000000000
 SigIgn:	0000000000380000
 SigCgt:	0000000100000000
 CapInh:	0000000000000000
 CapPrm:	0000000000000000
 CapEff:	0000000000000000
 CapBnd:	000001ffffffffff
 CapAmb:	0000000000000000
 NoNewPrivs:	0
 Seccomp:	0
 Seccomp_filters:	0
 Speculation_Store_Bypass:	thread vulnerable
 SpeculationIndirectBranch:	conditional enabled
 Cpus_allowed:	f
 Cpus_allowed_list:	0-3
 Mems_allowed:	00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
 Mems_allowed_list:	0
 voluntary_ctxt_switches:	421567
 nonvoluntary_ctxt_switches:	45955
Signal: 11
Uname: Linux 5.19.0-32-generic x86_64
UserGroups: adm cdrom dialout dip lpadmin lxd plugdev sambashare sudo
CoreDump: base64
 H4sICAAAAAAC/0NvcmVEdW1wAA==
 vL153CVVdfe7Gp5mEIFi0JjgtUscQhITywFBMXYhasAwlDjEgJFqBgUxsRx4I+hrF2AE1Lype1/BWQplcuKtJBqjoF0yaBRMKhGHG5NQyqxRSs0gk327a//WPmev2pun1vPHPZ8Pn8Xv1+d71t5rDzWc4dn8/CNfsMO6dcSPFXoOLRRRStNHSgfTb+/CzzePR319neeZRDc9cUevv86y642R/3yffV629ISI406OXsdEBK641+X4kb9wwq0sc91h+3q58qCH5vK3uFy8zo1L3NjyBO0v37qvv3/k51JwleDSdW6UXLkz2rnnIxyuu2UHJ0ouu3MHPPPvrty83M4dRFxwJs/deL0dXI4fw4M7PiTXbv2GlwvVhblOcqUbJ/lOM+3oNv+9Lh+4XnKr5bsb3FZlPnCD5FbLd5pZTsPmf1D2D0u4/Ie5+dBOXvqdar4UP1rBv3dz58v6ZY7Sm918zE37Z5oPbhCcfcQTbsXhcn++UD0rbucmHVdzXTb52xkH+sdctdnPrZavllzpxkm+081GWG9V5gPXSG61fD8Ct/lbyv4ZrpXcavlONxtvu1WZD1wnudXy/Qjc5m8r+2e4XnKr5TvdHCD6rcp8

JonB

@Qt-embedded-developer said in can anybody suggest the way to find hang and Crash issue in auto start based qt application ?:

@JoeCFD i have generated core dump file.

You mean as I suggested you do but you didn't respond to?

I don't know what command you are using to show the core dump file. A core dump file is a large binary file, usually named core. Once you have it you need to run

gdb /path/to/your/executable /path/to/the/core/file

and then type into gdb command bt to see the backtrace.

In order to generate a usable core file in a known place you must Google for core dump against whatever distro of Linux you are using. In the old days it just put a core for you to use in the current directory, nowadays you potentially have to do all sorts of stuff to tell Linux you want it to save the file (e.g. see ulimit and /proc/sys/kernel/core_pattern or sysctl kernel.core_pattern).

Qt embedded developer

@JonB Thanks now i got understand. i will try to generate core dump file and after that i will follow your steps.

i my log last line is :

could not parse float to string NA;

JonB

@Qt-embedded-developer
So that looks the reason. You can look at the backtrace now from the core if you need to.

could not parse float to string NA;

Is that your own message? I cannot imagine this is a "proper" message. One does not "parse" floats, one parses strings. Sounds like something about a float/string is not in the right format.

Qt embedded developer

@JonB i am getting the below output when check back trace

(gdb) bt
#0  StatusController::slotPollingRequested (this=0x55fe909f49d0)
    at ../../appDir/appDirComponents/controllers/statuscontroller.cpp:516
#1  0x000055fe8fe92047 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, bool (StatusController::*)()>::call(bool (StatusController::*)(), StatusController*, void**) (
    f=(bool (StatusController::*)(StatusController * const)) 0x55fe8fe72b7c <StatusController::slotPollingRequested()>, o=0x55fe909f49d0, arg=0x7ffc9a501b60)
    at /home/terumo/Qt5.15.8/5.15.8/gcc_64/include/QtCore/qobjectdefs_impl.h:152
#2  0x000055fe8fe91bb4 in QtPrivate::FunctionPointer<bool (StatusController::*)()>::call<QtPrivate::List<>, void>(bool (StatusController::*)(), StatusController*, void**) (
    f=(bool (StatusController::*)(StatusController * const)) 0x55fe8fe72b7c <StatusController::slotPollingRequested()>, o=0x55fe909f49d0, arg=0x7ffc9a501b60)
    at /home/terumo/Qt5.15.8/5.15.8/gcc_64/include/QtCore/qobjectdefs_impl.h:185
#3  0x000055fe8fe9107c in QtPrivate::QSlotObject<bool (StatusController::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x55fe90a0c850, r=0x55fe909f49d0, a=0x7ffc9a501b60, 
    ret=0x0)
    at /home/terumo/Qt5.15.8/5.15.8/gcc_64/include/QtCore/qobjectdefs_impl.h:418

JonB

@Qt-embedded-developer
And? It tells you the file and line number in your code where it crashes, so....

Qt embedded developer

@JonB i have resolved this above problem. but still app crash.

and in this time bt shows nothing.

i have check memory using top command and at that time remaining free memory was quiet low

i.e. from 4000 mb, remaining free memory is 100 mb.

So is there another way to find this type of crash ?

jsulm

@Qt-embedded-developer said in can anybody suggest the way to find hang and Crash issue in auto start based qt application ?:

So is there another way to find this type of crash ?

If you suspect that you have a memory leak use Valgrind to analyse your app (QtCreator supports it).

Qt embedded developer

@jsulm and @JonB i have used Valgrind tool but it not shows the any memory leak.

JonB

@Qt-embedded-developer
Then maybe you don't have any memory leak, maybe your code (or other stuff on machine) uses up a lot of memory without a "leak". But that does not mean it has to use that much memory, valgrind etc. can only tell you if you leak, not that (perhaps, perhaps not) your algorithm might be improved....

In general, make sure you free objects as soon as you don't need them again. Just as an example: suppose you create some large images in memory. So long as valgrind does not detect you have "lost" the pointer to it, so you will still be able to free it later, it can't complain. But if you keep them all in memory at the same time you will be using a lot of room....

Qt embedded developer

@JonB may be yes because i also seen that memory is usually increase slowly with time on particular 2 screen

1] screen that update 42 parameters every 1 second using qAbstractlist model

2] screen that show live data on graph screen . where at a time in one thread 4 data get shown on graph screen.

JonB

@Qt-embedded-developer
I appended an extra paragraph to my previous before I saw your reply.

Neither of what you mention is something we can tell you about. Qt in itself will not "leak" nor "hang onto things" which you have freed. Your own code and whether it behaves "best" is a different matter....

4 data get shown on graph screen

Whatever this means, for example if you plot enough points (millions? billions?) without removing some you will eventually keep using more and more memory....

Qt embedded developer

@JonB I have found that my code has issue due passing value using pointer.

so passing by value have resolved the Crash issue.

Now my error list is not passed by pointer its passed directly.

This issue identified by GDB. As well as valgrind tool also helps.