system() call timing issue - again
-
According to vague documentation - not Qt - system command processor (??) will eventually complete the system(...) call.
In my usage the system call builds two text files and writes to console.
I have no control how long it will take, which does not bother my application , but it bothers GDB .
Makes debugging a challenge to both GDB and Qt and my OS !It looks as GDB will totally break - quits - after about 20 seconds...
Can I , strictly for debugging purpose , modify / change / permanently increase this GDB "timeout " ?Yes, I can add timing delay to system call , but it is a debugging issue I am trying to solve.
The option of "giving GDB more time " is NOT a solution , it will eventually quit
-
Best guess: Execute
show watchdog(probably shows about 20 (seconds)) insidegdb
You can add a correctingset watchdogcommand to your.gdbinitfileAssuming this is actually a Qt program that you are using the system() call in you could redesign it to use QProcess. QProcess is non-blocking if used correctly.
-
This is even worse...
I get this "response " after "button click" and when first function is called.
The is NO system call, just plain "do a function ".The break point is set on first line of the function, no "action" is being performed.
This cannot be correct...
GDB is not working correctly and I have no idea how to fix it.
PS I do not want to **fool around with QProcess - been there , done that ** and it is NOT what I need to run my application.
I like KISS approach.
-
Given that GDB did not stop at your "break point is set on first line of the function," it is fair to assume that this code was not called called before your program crashed/or GDB crashed. Walk your breakpoint back until you find where it dies.
PS I do not want to **fool around with QProcess - been there , done that ** and it is NOT what I need to run my application.
Your choice.