[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | DECthreads Conference |
|
Moderator: | PTHRED::MARYS TE ON |
|
Created: | Mon May 14 1990 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 1553 |
Total number of notes: | 9541 |
1506.0. "cma_alloc_mem help" by EDSCLU::KELLY () Thu Mar 13 1997 19:52
We received a core file from a customer and can not determine the problem.
I have included output from DECLADEBUG and DBX.
The DBX output shows "cma_alloc_mem". In note 968.1 it says that CMA_ALLOC
is only used in old versions of VMS or ULTIX. Is this the same routine ? The
core file is from a DUNIX 3.2 machine. Does this look like a memory resource
problem ?
Any input or suggestions would be greatly appreciated.
Thanks,
Jim Kelly
==============================================================================
The machine is DUNIX 3.2
----------------------------------
The output from DECLADEBUG:
----------------------------------
>>decladebug /usr/sbin/t21cad /kkk/peer/work/bank_of_ireland-core
Welcome to the Ladebug Debugger Version 4.0-27
------------------
object file name: /usr/sbin/t21cad
core file name: /kkk/peer/work/bank_of_ireland-core
Reading symbolic information ...done
Core file produced from executable t21cad
Thread 0xffffffff827bad80 terminated at PC 0x3ff805065c8 by signal SEGV
(ladebug) where
>0 0x3ff805065c8 in UnknownProcedure18FromFile238(0x0, 0x0, 0x0, 0x0,
0x3ff8055c764, 0x0) DebugInformationStrippedFromFile238
#1 0x3ff8055c760 in /usr/shlib/libpthreads.so
ladebug) show thread
Id State
>* 0xffffffff827bad80 dead
0xffffffff827bb9e0 dead
0xffffffff827baea0 dead
0xffffffff827bae10 dead
0xffffffff827bacf0 dead
0xffffffff827bac60 dead
0xffffffff827babd0 dead
0xffffffff827bab40 dead
0xffffffff827baab0 dead
0xffffffff827baa20 dead
0xffffffff827ba990 dead
0xffffffff827ba900 dead
0xffffffff827ba5a0 dead
0xffffffff827ba510 dead
0xffffffff827ba480 dead
0xffffffff827ba3f0 dead
0xffffffff827ba360 dead
0xffffffff827eb3b0 dead
---------------------------------
The output from DBX:
---------------------------------
# dbx /usr/sbin/t21cad /kkk/peer/work/bank_of_ireland-core
dbx version 3.11.8
Type 'help' for help.
Core file created by program "t21cad"
thread 0xffffffff827bad80 signal Segmentation fault at >*[(unknown),
0x3ff805065c8] bis r0, r0, r27
(dbx) where
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff805065c8]
>>dbx) tstack
Thread 0xffffffff827bad80:
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff805065c8]
Thread 0xffffffff827bb9e0:
> 0 (unknown)(0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff,
0xffffffffffffffff, 0xffffffffffffffff) [0x3ff80505a54]
1 iscntrl(0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff,
0xffffffffffffffff, 0xffffffffffffffff) [0x3ff8011b54c]
Thread 0xffffffff827baea0:
> 0 host_callout_statistics_reset(0x0, 0x3ff80564598, 0x0, 0x0, 0x3ffc01e3de0)
[0x3ff8051df00]
1 cma__alloc_mem(0x3ff80562f54, 0x0, 0x3fffffcadd0, 0x3ffc01ea910,
0x3ffc01ea408) [0x3ff80574afc]
Thread 0xffffffff827bae10:
> 0 host_callout_statistics_reset(0x0, 0x3ff80564598, 0x0, 0x0, 0x3ffc01e3de0)
[0x3ff8051df00]
1 cma__alloc_mem(0x3ff80562f54, 0x0, 0x3fffffcadd0, 0x3ffc01f6910,
0x3ffc01f6408) [0x3ff80574afc]
Thread 0xffffffff827bacf0:
> 0 host_callout_statistics_reset(0x0, 0x3ff80564598, 0x0, 0x0, 0x3ffc01e3de0)
[0x3ff8051df00]
More (n if no)?
1 cma__alloc_mem(0x3ff80562f54, 0x0, 0x3fffffcadd0, 0x3ffc020e910,
0x3ffc020e408) [0x3ff80574afc]
Thread 0xffffffff827bac60:
> 0 host_callout_statistics_reset(0x0, 0x3ff80564598, 0x0, 0x0, 0x3ffc01e3de0)
[0x3ff8051df00]
1 cma__alloc_mem(0x3ff80562f54, 0x0, 0x3fffffcadd0, 0x3ffc021a910,
0x3ffc021a408) [0x3ff80574afc]
Thread 0xffffffff827babd0:
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff805075b0]
Thread 0xffffffff827bab40:
> 0 host_callout_statistics_reset(0x0, 0x3ff80564598, 0x0, 0x0, 0x3ffc01e3de0)
[0x3ff8051df00]
1 cma__alloc_mem(0x3ff80562f54, 0x0, 0x3fffffcadd0, 0x3ffc0232910,
0x3ffc0232408) [0x3ff80574afc]
Thread 0xffffffff827baab0:
> 0 host_callout_statistics_reset(0x0, 0x3ff80564598, 0x0, 0x0, 0x3ffc01e3de0)
[0x3ff8051df00]
1 cma__alloc_mem(0x3ff80562f54, 0x0, 0x3fffffcadd0, 0x3ffc023e910,
0x3ffc023e408) [0x3ff80574afc]
Thread 0xffffffff827baa20:
More (n if no)?
> 0 host_callout_statistics_reset(0x0, 0x3ff80564598, 0x0, 0x0, 0x3ffc01e3de0)
[0x3ff8051df00]
1 cma__alloc_mem(0x3ff80562f54, 0x0, 0x3fffffcadd0, 0x3ffc024a910,
0x3ffc024a408) [0x3ff80574afc]
Thread 0xffffffff827ba990:
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff80505a90]
1 get_dir_ent(prefix = (nil))
["/usr/users/snagwy/sna5/pai_eco06/aosf/gciosf/src/gcilu.c":2949, 0x120027f48]
Thread 0xffffffff827ba900:
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff80505a90]
1 get_dir_ent(prefix = (nil))
["/usr/users/snagwy/sna5/pai_eco06/aosf/gciosf/src/gcilu.c":2949, 0x120027f48]
Thread 0xffffffff827ba5a0:
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff80505a90]
1 get_dir_ent(prefix = (nil))
["/usr/users/snagwy/sna5/pai_eco06/aosf/gciosf/src/gcilu.c":2949, 0x120027f48]
Thread 0xffffffff827ba510:
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff80505a90]
1 get_dir_ent(prefix = (nil))
["/usr/users/snagwy/sna5/pai_eco06/aosf/gciosf/src/gcilu.c":2949, 0x120027f48]
More (n if no)?
hread 0xffffffff827ba510:
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff80505a90]
1 get_dir_ent(prefix = (nil))
["/usr/users/snagwy/sna5/pai_eco06/aosf/gciosf/src/gcilu.c":2949, 0x120027f48]
More (n if no)?
Thread 0xffffffff827ba480:
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff80505a90]
1 get_dir_ent(prefix = (nil))
["/usr/users/snagwy/sna5/pai_eco06/aosf/gciosf/src/gcilu.c":2949, 0x120027f48]
Thread 0xffffffff827ba3f0:
> 0 (unknown)(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff80505a90]
1 get_dir_ent(prefix = (nil))
["/usr/users/snagwy/sna5/pai_eco06/aosf/gciosf/src/gcilu.c":2949, 0x120027f48]
Thread 0xffffffff827ba360:
0 (noname)() [0x120000000]
Thread 0xffffffff827eb3b0:
0 (noname)() [0x120000000]
(dbx) tlist
thread 0xffffffff827bad80 signal Segmentation fault at >*[(unknown),
0x3ff805065c8] bis r0, r0, r27
thread 0xffffffff827bb9e0 stopped at >*[(unknown), 0x3ff80505a58] cmpeq
r9, 0x30, r5
thread 0xffffffff827baea0 stopped at >*[host_callout_statistics_reset,
0x3ff8051df04] bne r16, 0x3ff8051df10
thread 0xffffffff827bae10 stopped at >*[host_callout_statistics_reset,
0x3ff8051df04] bne r16, 0x3ff8051df10
thread 0xffffffff827bacf0 stopped at >*[host_callout_statistics_reset,
0x3ff8051df04] bne r16, 0x3ff8051df10
thread 0xffffffff827bac60 stopped at >*[host_callout_statistics_reset,
0x3ff8051df04] bne r16, 0x3ff8051df10
thread 0xffffffff827babd0 stopped at >*[(unknown), 0x3ff805075b4] bne
r0, 0x3ff805075d0
thread 0xffffffff827bab40 stopped at >*[host_callout_statistics_reset,
0x3ff8051df04] bne r16, 0x3ff8051df10
thread 0xffffffff827baab0 stopped at >*[host_callout_statistics_reset,
0x3ff8051df04] bne r16, 0x3ff8051df10
thread 0xffffffff827baa20 stopped at >*[host_callout_statistics_reset,
0x3ff8051df04] bne r16, 0x3ff8051df10
thread 0xffffffff827ba990 stopped at >*[(unknown), 0x3ff80505a94] and
r17, 0x10, r17
thread 0xffffffff827ba900 stopped at >*[(unknown), 0x3ff80505a94] and
r17, 0x10, r17
More (n if no)?
thread 0xffffffff827ba3f0 stopped at >*[(unknown), 0x3ff80505a94] and
r17, 0x10, r17
thread 0xffffffff827ba360 stopped at
warning: PC value 0x0 not valid, trying RA
warning: RA value 0x0 not valid, trying text start
warning: text start 0x120000000 not valid, trying data start
warning: Using data start as a text address -- traceback will not work
> [., 0x140000000] call_pal cflush
thread 0xffffffff827eb3b0 stopped at
warning: PC value 0x0 not valid, trying RA
warning: RA value 0x0 not valid, trying text start
warning: text start 0x120000000 not valid, trying data start
warning: Using data start as a text address -- traceback will not work
> [., 0x140000000] call_pal cflush
(dbx)
T.R | Title | User | Personal Name | Date | Lines |
---|
1506.1 | | DCETHD::BUTENHOF | Dave Butenhof, DECthreads | Fri Mar 14 1997 07:14 | 15 |
| Are you sure you were running the debugger on the same O/S version, with all
the same libraries, as the original application that generated the core file?
The stack traces are not sensible. While there was a routine called
"cma__alloc_mem" (note the double underscores -- this is an internal routine
that we used to manage our own memory on top of the system allocator, with
our own caching mechanism), it did not call "host_callout_statistics_reset"
(whatever that is). And, of course, cma__alloc_mem must always have BEEN
called by something -- and none of the stacks show additional frames.
My first guess is that either the core file is corrupted (for unknown
reasons) or you're viewing it with mismatched libraries (which would change
the symbol addresses, and make the results meaningless).
/dave
|
1506.2 | What Dave said. | WTFN::SCALES | Despair is appropriate and inevitable. | Fri Mar 14 1997 09:48 | 10 |
| .0> thread 0xffffffff827bad80 signal Segmentation fault at
.0> >*[(unknown), 0x3ff805065c8] bis r0, r0, r27
You definitely have matching problems -- this instruction (where the debugger
reports a SIGSEGV was delivered) cannot cause a segmentation fault. (So,
unless someone or something is using kil to send SIGSEGVs around, you're
suffering from a code skew...)
Webb
|
1506.3 | cma_alloc_mem | EDSCLU::KELLY | | Wed Mar 19 1997 09:53 | 9 |
| Thanks for your input and analysis.
We are having the customer run a dbx() session on
their machine to validate the core file. I think it is possible
that they issued a kill command to cause the core.
Regards,
Jim Kelly
|
1506.4 | Use SIGQUIT to asynchronously generate a core file. | WTFN::SCALES | Despair is appropriate and inevitable. | Wed Mar 19 1997 11:37 | 7 |
| .3> I think it is possible that they issued a kill command to cause the core.
If that turns out to be the case, please advise them to use SIGQUIT in the
future, instead of SIGSEGV -- it'll save a good bit of confusion....
Webb
|