MC > “Maa” <> maa_vip@sina.com> > wrote in message news:cig85e$cn1$> 1@inn.qnx.com> …
Mario, when I dump a process, I’ll press dumper -d /home/dump/ -p pid &
then change to the directory and press
wd -tr=pmd proesee_name.dmp
But the tool tell me the file format error.
MC > Never seen that happens. Don’t have a clue what could be the cause of the
MC > problem. Hopefuly someone else will comment.
This sounds like an old versionitus problem I remember
The version of dumper is not compatable with the version of wd.
Can you post the file dates and sizes of both dumper and wd and hopfully
someone can send you the newer version of whichever?
Actually, might not be versionitis, entirely. Early in the life
of dumper, it dumped out ALL the address space of the process, whether
there was actual RAM there or not. Later in the life of dumper, it
started creating “sparse” dump files, or at least had that capability.
“wd -tr=pmd” will load the non-sparse dump files.
“wd -tr=sparse” will load the sparse dump files.
So, it might be be a sparse/not-sparse issue.
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services dagibbs@qnx.com
First, I dumper a generic process such as Net or inetd, everything is okay,
and I can parse the *.dmp file by wd utility. But when I dumper my process,
the operation system freeze suddenly just like the status what I said
before.
1, I run my process, and it’s okay;
2, I dumper it, and it’s okay too;
dumper -d /home/dump/ -p pid &
3, Then I kill the process, but when I press the enter key, the OS freeze,
and the order is:
slay -s sigsegv processname or
kill -sigsegv pid
First, I dumper a generic process such as Net or inetd, everything is
okay,
and I can parse the *.dmp file by wd utility. But when I dumper my
process,
the operation system freeze suddenly just like the status what I said
before.
1, I run my process, and it’s okay;
2, I dumper it, and it’s okay too;
dumper -d /home/dump/ -p pid &
3, Then I kill the process, but when I press the enter key, the OS freeze,
and the order is:
slay -s sigsegv processname or
kill -sigsegv pid
Just at though; does your process thread or tfork()?
“Maa” <> maa_vip@sina.com> > wrote in message news:ciu5uc$2ks$> 1@inn.qnx.com> …
There are some interesting things in my test.
First, I dumper a generic process such as Net or inetd, everything is
okay,
and I can parse the *.dmp file by wd utility. But when I dumper my
process,
the operation system freeze suddenly just like the status what I said
before.
1, I run my process, and it’s okay;
2, I dumper it, and it’s okay too;
dumper -d /home/dump/ -p pid &
3, Then I kill the process, but when I press the enter key, the OS
freeze,
and the order is:
slay -s sigsegv processname or
kill -sigsegv pid
Yes, there is one main process and it has 5 threads which created by
tfork().
I see, someone says that it is dangerous that use thread and tfork() in
qnx4
OS, but I really don’t know what’s the danger and how to avoid it?
Well now you know of one reason, dumper/wd is “incompatible” with threads…
Threads is somewhat of a kludge in QNX4, some C functions are not thread
safe, file handle are not thread safe. Photon lib isn’t thread safe, TCP/IP
isn’t thread safe.
Is there any other good idea if do not use thread and tfork()? And what’s
your advice?
Use separate processes and exchange data via messaging or share memory.
Just at though; does your process thread or tfork()?
“Maa” <> maa_vip@sina.com> > wrote in message
news:ciu5uc$2ks$> 1@inn.qnx.com> …
There are some interesting things in my test.
First, I dumper a generic process such as Net or inetd, everything is
okay,
and I can parse the *.dmp file by wd utility. But when I dumper my
process,
the operation system freeze suddenly just like the status what I said
before.
1, I run my process, and it’s okay;
2, I dumper it, and it’s okay too;
dumper -d /home/dump/ -p pid &
3, Then I kill the process, but when I press the enter key, the OS
freeze,
and the order is:
slay -s sigsegv processname or
kill -sigsegv pid
Yes, there is one main process and it has 5 threads which created by
tfork().
I see, someone says that it is dangerous that use thread and tfork() in
qnx4
OS, but I really don’t know what’s the danger and how to avoid it?
MC > Well now you know of one reason, dumper/wd is “incompatible” with threads…
MC > Threads is somewhat of a kludge in QNX4, some C functions are not thread
MC > safe, file handle are not thread safe. Photon lib isn’t thread safe, TCP/IP
MC > isn’t thread safe.
Is there any other good idea if do not use thread and tfork()? And what’s
your advice?
MC > Use separate processes and exchange data via messaging or share memory.
Maa
2004-09-24
What bugged me was that errno wasn’t thread safe. The obvious choice for
threads is a communications thread and a worker thread. But my
communications thread was constantly being fooled by errnos that were set
in the main thread. You could never test WHY something failed.