Any special requirements in a module to debug?
-
@JonB , have cleaned and rebuilt all, set a break point on the first line of main() and another in the file I'm having problems on the line that outputs to the Application Output.
It stopped on the breakpoint in main(), but didn't stop on the breakpoint in the module I'm having difficulty with.
@SPlatten
The breakpoint looks like it is active and in the right place. Trouble is, if somehow source code and debug info are out of sync this happens, don't I know.... BTW is this "module" part of current project compilation, not in something else external you're linking with?Put the breaks all over the offending module, especially in the constructor. Don't 100% rely on one statement being hit. Put in a
qDebug()message where the break is to prove to yourself, me & the wider world that the break is definitely being hit. -
@JonB , now I feel rather foolish....a rather large penny has just dropped....the file I'm having difficulty with is used not only by the main process but also by a child process it launches and its the child processes output that Im seeing in the Application Output.
Kind Regards,
Sy -
@JonB , now I feel rather foolish....a rather large penny has just dropped....the file I'm having difficulty with is used not only by the main process but also by a child process it launches and its the child processes output that Im seeing in the Application Output.
@SPlatten said in Any special requirements in a module to debug?:
the file I'm having difficulty with is used not only by the main process but also by a child process it launches and its the child processes output that Im seeing in the Application Output.
There was a way to tell Creator/gdb how to behave when
fork()ing, but for the life of me I can't remember where this was set. By default it switches to the child, but it can be made so it stays with the parent, I'm positive.Read and abide by the Qt Code of Conduct
-
@SPlatten said in Any special requirements in a module to debug?:
the file I'm having difficulty with is used not only by the main process but also by a child process it launches and its the child processes output that Im seeing in the Application Output.
There was a way to tell Creator/gdb how to behave when
fork()ing, but for the life of me I can't remember where this was set. By default it switches to the child, but it can be made so it stays with the parent, I'm positive.@kshegunov said in Any special requirements in a module to debug?:
By default it switches to the child,
? :)
https://sourceware.org/gdb/onlinedocs/gdb/Forks.htmlBy default, when a program forks, GDB will continue to debug the parent process and the child process will run unimpeded.
If you want to follow the child process instead of the parent process, use the command
set follow-fork-mode. -
@kshegunov said in Any special requirements in a module to debug?:
By default it switches to the child,
? :)
https://sourceware.org/gdb/onlinedocs/gdb/Forks.htmlBy default, when a program forks, GDB will continue to debug the parent process and the child process will run unimpeded.
If you want to follow the child process instead of the parent process, use the command
set follow-fork-mode.@JonB said in Any special requirements in a module to debug?:
By default, when a program forks, GDB will continue to debug the parent process and the child process will run unimpeded.
If you want to follow the child process instead of the parent process, use the command
set follow-fork-mode.Well, I suppose my frail memory has failed me yet again and I have remembered it exactly in the opposite way of how it is. What can I say ... in any case if the child's is the one supposed to trap the breakpoint, then @SPlatten should use that switch (set where the
gdb's additional arguments are supplied - in the debugger configuration pane of Creator).Read and abide by the Qt Code of Conduct
-
@JonB said in Any special requirements in a module to debug?:
By default, when a program forks, GDB will continue to debug the parent process and the child process will run unimpeded.
If you want to follow the child process instead of the parent process, use the command
set follow-fork-mode.Well, I suppose my frail memory has failed me yet again and I have remembered it exactly in the opposite way of how it is. What can I say ... in any case if the child's is the one supposed to trap the breakpoint, then @SPlatten should use that switch (set where the
gdb's additional arguments are supplied - in the debugger configuration pane of Creator). -
@kshegunov
:)
I think @SPlatten was just reporting what he sees in output, not whether the debugger moves to the sub-process or notits the child processes output that Im seeing in the Application Output
But yours is indeed useful to know, thanks.
@JonB said in Any special requirements in a module to debug?:
I think @SPlatten was just reporting what he sees in output, not whether the debugger moves to the sub-process or not
Let's try my memory again, shall we?
He's getting output from the current attached terminal, which is the parent, joined after a singlefork(), the parent after a doublefork()or the child withset follow-fork-modeafter a doublefork(). Be sure to shoot me down if I'm mistaken. :)Read and abide by the Qt Code of Conduct
-
@JonB said in Any special requirements in a module to debug?:
I think @SPlatten was just reporting what he sees in output, not whether the debugger moves to the sub-process or not
Let's try my memory again, shall we?
He's getting output from the current attached terminal, which is the parent, joined after a singlefork(), the parent after a doublefork()or the child withset follow-fork-modeafter a doublefork(). Be sure to shoot me down if I'm mistaken. :)@kshegunov
He's OK. You need thespoon()method :)Actually, I see what you mean, maybe he did want to switch to debugging the child process. But when the
fork()thenexec()s, will thegdbfollow that (to the new process) just because of fork mode? -
@kshegunov
He's OK. You need thespoon()method :)Actually, I see what you mean, maybe he did want to switch to debugging the child process. But when the
fork()thenexec()s, will thegdbfollow that (to the new process) just because of fork mode?@JonB said in Any special requirements in a module to debug?:
But when the fork() then exec()s, will the gdb follow that (to the new process) just because of fork mode?
If I understand the question correctly, yes.
Read and abide by the Qt Code of Conduct
-
@JonB said in Any special requirements in a module to debug?:
But when the fork() then exec()s, will the gdb follow that (to the new process) just because of fork mode?
If I understand the question correctly, yes.
If you have set
detach-on-forktoon, GDB will debug both the parent and the child process.Put that on your fork and eat it! ;)
Also I found
If you ask to debug a child process and a vfork is followed by an exec, GDB executes the new target up to the first breakpoint in the new target. If you have a breakpoint set on main in your original program, the breakpoint will also be set on the child process’s main.
Nice one :)
-
If you have set
detach-on-forktoon, GDB will debug both the parent and the child process.Put that on your fork and eat it! ;)
Also I found
If you ask to debug a child process and a vfork is followed by an exec, GDB executes the new target up to the first breakpoint in the new target. If you have a breakpoint set on main in your original program, the breakpoint will also be set on the child process’s main.
Nice one :)
@JonB said in Any special requirements in a module to debug?:
GDB will debug both the parent and the child process.
This is going to be just very confusing, if you ask me ... I'd rather keep only one victim on a fork.
