| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1521.1 | Probably not... | DCETHD::BUTENHOF | Dave Butenhof, DECthreads | Thu Apr 10 1997 13:28 | 27 |
| >I know little of DECthreads: is this likely to be a bug within it,
>and why are there so few stack frames in the dbx output (i.e. the product
>itself does not seem to contribute at all!)
Are you sure you're looking at the core file on a system with the EXACT same
software as the system on which it was generated? Having one or more
different libraries can result in incorrect address resolution and misleading
display. Those probably are NOT the actual routines. And, in the unlikely
event that you are looking at it with all the right libraries, or that this
stack trace was generated by the customer in the EXACT same environment as
the original "crash", then the stack is so hopelessly corrupted as to be
meaningless.
First off, it is IMPOSSIBLE for cma__int_mutex_block to appear as the first
frame in a call stack. Therefore that's NOT the bottom, or it's not really
cma__int_mutex_block. IF your addresses were correct, then the stack must
continue past that point -- and either the core file or the stack is busted.
Second, cma__int_mutex_block does not and cannot under any circumstances be
made to call _dsto2fp() -- whatever that is. (So the addresses CANNOT be
correct.)
Either the data is meaningless, or it's being incorrectly interpreted. Choose
one. And, next time, please walk slowly and deliberately toward conclusions,
instead of jumping wildly.
/dave
|
| 1521.2 | | FORTY2::BOYES | My karma ran over my dogma | Thu Apr 10 1997 13:35 | 9 |
| Thanks for your input: the dump was not analysed on the same system that
produced it, but I (unreasonably) expected it to work due to another core dump
from the same product (not using DECthreads) having been successfully analysed
on the different system.
Please note by base note contained no conclusions, only questions, which have
been answered.
+Mark+
|
| 1521.3 | | SMURF::DENHAM | Digital UNIX Kernel | Thu Apr 10 1997 14:07 | 6 |
| Are there more than 15 or 16 threads in the application? If so,
the core file will indeed be corrupted. A V3.2-based fix for
the kernel's core() function is in the works to fix this.
If that's the problem, of course. For more info on the kernel
patch, send mail to Bill Arvidson -- arvidson@zk3.dec.com
or guru::arvidson.
|
| 1521.4 | | DCETHD::BUTENHOF | Dave Butenhof, DECthreads | Thu Apr 10 1997 16:40 | 14 |
| >Please note by base note contained no conclusions, only questions, which
>have been answered.
Someone pointed this out to me, and, on re-reading your note, your intent is
obvious. However (and I'm not attempting to be satirical here), it is
traditional to end a question with a question mark symbol. I guess this is
like those optical illusions where you see one of two different pictures
depending on how you first perceive the image. The lack of a question mark
somehow caused me to read your sentence as a (very) poorly PHRASED statement
rather than as a (slightly) poorly PUNCTUATED question.
Sorry.
/dave
|
| 1521.5 | | FORTY2::BOYES | My karma ran over my dogma | Mon Apr 14 1997 12:21 | 8 |
| Re: 3.
That could be it. There can be up to fifty threads (though more than twenty
is highly unlikely). I will wait to see what the dump looks like at its
source before mailing Bill.
Thanks,
+Mark+
|