I tried the “-p” option as documented for QCC, but no
profile data came out. Does that feature work? Thanks.
Using 6.20 NC.
John Nagle
Animats
When you run an application with profiling data, you will get a file called
‘gmon.out’. Then, if you run ‘gprof <your_app>’, gprof will read the
gmon.out file and print profiling data.
cheers,
Kris
“John Nagle” <nagle@downside.com> wrote in message
news:b2e9m6$scn$1@inn.qnx.com…
I tried the “-p” option as documented for QCC, but no
profile data came out. Does that feature work? Thanks.Using 6.20 NC.
John Nagle
Animats
Also note that you need to compile and link with -p and you must run the
app to be profiled as root.
chris
Kris Warkentin <kewarken@qnx.com> wrote:
When you run an application with profiling data, you will get a file called
‘gmon.out’. Then, if you run ‘gprof <your_app>’, gprof will read the
gmon.out file and print profiling data.cheers,
Kris
“John Nagle” <> nagle@downside.com> > wrote in message
news:b2e9m6$scn$> 1@inn.qnx.com> …
I tried the “-p” option as documented for QCC, but no
profile data came out. Does that feature work? Thanks.Using 6.20 NC.
John Nagle
Animats
\
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris McKillop <cdm@qnx.com> wrote:
Kris Warkentin <> kewarken@qnx.com> > wrote:
When you run an application with profiling data, you will get a file
called ‘gmon.out’. Then, if you run ‘gprof <your_app>’, gprof will read
the gmon.out file and print profiling data.
Also note that you need to compile and link with -p and you must run
the app to be profiled as root.
And the gmon.out is written only at atexit/fini time, so your app
must exit() cleanly (or fall through main()). And the gmon.out file
goes in the current directory, so be careful looking for it if you’ve
chdir()d or procmgr_daemon()d.
John Garvey wrote:
And the gmon.out is written only at atexit/fini time, so your app
must exit() cleanly (or fall through main()). And the gmon.out file
goes in the current directory, so be careful looking for it if you’ve
chdir()d or procmgr_daemon()d.
I think termination is the problem; it’s a resource manager
with multiple threads. Does the initial thread have to exit last,
or are there other constraints on threads?
John Nagle
Animats
John Nagle <nagle@downside.com> wrote:
John Garvey wrote:
And the gmon.out is written only at atexit/fini time, so your app
must exit() cleanly (or fall through main()). And the gmon.out file
goes in the current directory, so be careful looking for it if you’ve
chdir()d or procmgr_daemon()d.
I think termination is the problem; it’s a resource manager
with multiple threads. Does the initial thread have to exit last,
or are there other constraints on threads?
Guess the first thing to confirm is that you do have a profiling
version built: do a “nm” on your executable and look for a “_mcount”
symbol. Are all of your threads in the resmgr pool (ie did you
specify POOL_FLAG_USE_SELF) or does the first thread do something
else (in all my servers I have the main thread do a SignalWaitinfo()
to pick up signals which are blocked in all other threads). Don’t
think there are any thread-related constraints, pthread_exit() will
not do the profiling output burst but the termination of the final
thread is an implicit exit() which should do it. You could try
installing a SIGTERM handler that just calls exit(0). I assume
the cwd is writable (since you’re root not too hard to arrange).
I have successfully profiled multi-threaded resource managers
(but with the initial thread waiting in SignalWaitinfo() and
then explicitly calling exit() if that is indeed a factor) …
The main thing is that the atexit() handlers must be called, since the
profiling cleanup function void _mcleanup(void) is registered with that
mechanism.
You can probably call _mcleanup() manually if you really need to,
although I think you should probably exit directly afterwards.
John Garvey <jgarvey@qnx.com> wrote:
John Nagle <> nagle@downside.com> > wrote:
John Garvey wrote:
And the gmon.out is written only at atexit/fini time, so your app
must exit() cleanly (or fall through main()). And the gmon.out file
goes in the current directory, so be careful looking for it if you’ve
chdir()d or procmgr_daemon()d.
I think termination is the problem; it’s a resource manager
with multiple threads. Does the initial thread have to exit last,
or are there other constraints on threads?Guess the first thing to confirm is that you do have a profiling
version built: do a “nm” on your executable and look for a “_mcount”
symbol. Are all of your threads in the resmgr pool (ie did you
specify POOL_FLAG_USE_SELF) or does the first thread do something
else (in all my servers I have the main thread do a SignalWaitinfo()
to pick up signals which are blocked in all other threads). Don’t
think there are any thread-related constraints, pthread_exit() will
not do the profiling output burst but the termination of the final
thread is an implicit exit() which should do it. You could try
installing a SIGTERM handler that just calls exit(0). I assume
the cwd is writable (since you’re root not too hard to arrange).I have successfully profiled multi-threaded resource managers
(but with the initial thread waiting in SignalWaitinfo() and
then explicitly calling exit() if that is indeed a factor) …
Note also that if you set the environment variable PROFDIR, you will get
$PROFDIR/. instead of gmon.out. This can be handy for
multiple profiling runs.
cheers,
Kris
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:b2ga34$ioo$2@nntp.qnx.com…
The main thing is that the atexit() handlers must be called, since the
profiling cleanup function void _mcleanup(void) is registered with that
mechanism.You can probably call _mcleanup() manually if you really need to,
although I think you should probably exit directly afterwards.John Garvey <> jgarvey@qnx.com> > wrote:
John Nagle <> nagle@downside.com> > wrote:
John Garvey wrote:
And the gmon.out is written only at atexit/fini time, so your app
must exit() cleanly (or fall through main()). And the gmon.out file
goes in the current directory, so be careful looking for it if you’ve
chdir()d or procmgr_daemon()d.
I think termination is the problem; it’s a resource manager
with multiple threads. Does the initial thread have to exit last,
or are there other constraints on threads?Guess the first thing to confirm is that you do have a profiling
version built: do a “nm” on your executable and look for a “_mcount”
symbol. Are all of your threads in the resmgr pool (ie did you
specify POOL_FLAG_USE_SELF) or does the first thread do something
else (in all my servers I have the main thread do a SignalWaitinfo()
to pick up signals which are blocked in all other threads). Don’t
think there are any thread-related constraints, pthread_exit() will
not do the profiling output burst but the termination of the final
thread is an implicit exit() which should do it. You could try
installing a SIGTERM handler that just calls exit(0). I assume
the cwd is writable (since you’re root not too hard to arrange).I have successfully profiled multi-threaded resource managers
(but with the initial thread waiting in SignalWaitinfo() and
then explicitly calling exit() if that is indeed a factor) …
\
Also note that prior to 6.2.1, if qconn is running, gmon.out will not be
generated.
Jerry Chappell
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:b2ga34$ioo$2@nntp.qnx.com…
The main thing is that the atexit() handlers must be called, since the
profiling cleanup function void _mcleanup(void) is registered with that
mechanism.You can probably call _mcleanup() manually if you really need to,
although I think you should probably exit directly afterwards.John Garvey <> jgarvey@qnx.com> > wrote:
John Nagle <> nagle@downside.com> > wrote:
John Garvey wrote:
And the gmon.out is written only at atexit/fini time, so your app
must exit() cleanly (or fall through main()). And the gmon.out file
goes in the current directory, so be careful looking for it if you’ve
chdir()d or procmgr_daemon()d.
I think termination is the problem; it’s a resource manager
with multiple threads. Does the initial thread have to exit last,
or are there other constraints on threads?Guess the first thing to confirm is that you do have a profiling
version built: do a “nm” on your executable and look for a “_mcount”
symbol. Are all of your threads in the resmgr pool (ie did you
specify POOL_FLAG_USE_SELF) or does the first thread do something
else (in all my servers I have the main thread do a SignalWaitinfo()
to pick up signals which are blocked in all other threads). Don’t
think there are any thread-related constraints, pthread_exit() will
not do the profiling output burst but the termination of the final
thread is an implicit exit() which should do it. You could try
installing a SIGTERM handler that just calls exit(0). I assume
the cwd is writable (since you’re root not too hard to arrange).I have successfully profiled multi-threaded resource managers
(but with the initial thread waiting in SignalWaitinfo() and
then explicitly calling exit() if that is indeed a factor) …
\
Can we see qconn in pidin output?
Are you sure that gmon.out is generated for apps calling :
procmgr_daemon(EXIT_SUCCESS,
PROCMGR_DAEMON_NOCHDIR|PROCMGR_DAEMON_NODEVNULL);
I have a signal handler and I sure that exit(0) is called.
I have the _mcount symbol in the exe.
thanks,
Alain.
Jerry Chappell a écrit:
Also note that prior to 6.2.1, if qconn is running, gmon.out will not be
generated.Jerry Chappell
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:b2ga34$ioo$> 2@nntp.qnx.com> …
The main thing is that the atexit() handlers must be called, since the
profiling cleanup function void _mcleanup(void) is registered with that
mechanism.You can probably call _mcleanup() manually if you really need to,
although I think you should probably exit directly afterwards.John Garvey <> jgarvey@qnx.com> > wrote:
John Nagle <> nagle@downside.com> > wrote:
John Garvey wrote:
And the gmon.out is written only at atexit/fini time, so your app
must exit() cleanly (or fall through main()). And the gmon.out file
goes in the current directory, so be careful looking for it if you’ve
chdir()d or procmgr_daemon()d.
I think termination is the problem; it’s a resource manager
with multiple threads. Does the initial thread have to exit last,
or are there other constraints on threads?
Guess the first thing to confirm is that you do have a profiling
version built: do a “nm” on your executable and look for a “_mcount”
symbol. Are all of your threads in the resmgr pool (ie did you
specify POOL_FLAG_USE_SELF) or does the first thread do something
else (in all my servers I have the main thread do a SignalWaitinfo()
to pick up signals which are blocked in all other threads). Don’t
think there are any thread-related constraints, pthread_exit() will
not do the profiling output burst but the termination of the final
thread is an implicit exit() which should do it. You could try
installing a SIGTERM handler that just calls exit(0). I assume
the cwd is writable (since you’re root not too hard to arrange).
I have successfully profiled multi-threaded resource managers
(but with the initial thread waiting in SignalWaitinfo() and
then explicitly calling exit() if that is indeed a factor) …
\