[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decladebug

Title:	Digital Ladebug debugger

Moderator:	TLE::LUCIA

Created:	Fri Feb 28 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	969
Total number of notes:	3959

939.0. "V4.0-35 Assertion parsesymscoff.C 288" by CICS03::helen (Helen Pratt) Thu May 01 1997 05:56


I am working with a partner who is using Ladebug Version 4.0-35 on
Digital UNIX V4.0A with the BL4 patch.

They are attempting to attach to a several processes which are all
running the same executable and have been running overnight.  Each of
these processes cannot be attached to.  Is it possible that it's to do
with the state of these processes? This was working fine, but for some 
reason this morning it's not.  This is what they get:

# ladebug
Welcome to the Ladebug Debugger Version 4.0-35
(ladebug) attach 8914 /opt/cics/bin/cicsas
object file name: /opt/cics/bin/cicsas
Reading symbolic information ...done
Assertion failed: (lowLineNo > 0) && (highLineNo > 0) src/libsrc/ladebug/parsesy
mscoff.C 288
This is an unexpected condition and may indicate the presence of a defect.
If you wish to report this, please include the stack trace that follows.
Diagnostic stack trace ...
0x12449a14
0x1245c838
0x1245a27c
0x12459084
0x1242ff3c
0x124379ec
0x1238e6e8
0x123bcafc
0x123bc2d8
0x1255b3d0
0x12413668
0x124115a8
0x12383644
0x12226e4c
0x1224f030
0x12223424
0x12227970
0x12217bac
0x12214d7c
end of diagnostic stack trace.
Could not attach to process 8914.
No image loaded ... Recovering ... 


At this stage they kill ladebug.

Can anyone shed any light on why this might happen.

Thanks,

Helen.

T.R	Title	User	Personal Name	Date	Lines
939.1		TLE::LUCIA	http://asaab.zko.dec.com/~lucia/biography.html	`Fri May 02 1997 11:15`	19
	I can tell you what the error means. It means that while ladebug was reading symbolic line number information for a procedure, the condition described in the assertion failure did not hold true for the line numbers in the procedure descriptor in the symbol table. I.e., there is a procedure in this application who's line number information is damaged. Ladebug relies on the line number ranges to tell what procedure it is in relative to a line number and a file. Is this easily reproduceable? Does it only happen on attach? Does the binary have some non-debuggable (not built -g) or stripped portions? Can we get a copy of the binary? If not, then the output of odump -Pv on the binary would be acceptable, if it's okay with them. I suspect this is (at least partly) a Fortran application. What version of Fortran was used? I have a feeling I've seen this before and it was a regression in the 4.1 Fortran compilers, but I can't locate a note on it right now. Regards, Tim
939.2	Not Fortran.... C and COBOL...	CICS03::helen	Helen Pratt	`Thu May 08 1997 08:41`	37
	Tim, Thanks for the information on the problems attaching. The problem still persists, but only occurs some times. This is even for the same builds. >>Is this easily reproduceable? Does it only happen on attach? Does the binary >>have some non-debuggable (not built -g) or stripped portions? Can we get a copy >>of the binary? If not, then the output of odump -Pv on the binary would be >>acceptable, if it's okay with them. I have only seen this on the customer site, normally when they have run into a problem, so essentially not easily reproducable. Unfortuantely given the design of the product and the way it works starting a cicsas in the debugger is almost impossible, so we've only ever attached. The code is stripped and built non-dedebug (they're trying to stress test the final product). Are you still interested in the odump data - I'm sure we could get this. A copy of the binary isn't going to be straight forwards given that it's such a big product which multiple executables and libraries. >>I suspect this is (at least partly) a Fortran application. What version of >>Fortran was used? I have a feeling I've seen this before and it was a >>regression in the 4.1 Fortran compilers, but I can't locate a note on it right >>now. There's no Fortran in the there at all. There is however some COBOL (MF COBOL V4.0) and some (a very, very small amount) assembler. The cicsas process is just one of the CICS processes, it essentially runs the user supplied transactions which will be in either C or COBOL. Any insites gratefully received, Regards, Helen.
939.3		TLE::LUCIA	http://asaab.zko.dec.com/~lucia/biography.html	`Thu May 08 1997 14:59`	12
	The output of odump -Pv would be most helpful. I can then give you feedback on which routine(s) are causing trouble. Ladebug should tolerate this situation, although it probably can't help you debug a non -g binary that has been stripped. I'm not that enthusiastic about odump -Pv giving me that much information. We have minimal support for DEC COBOL but we do not support (or pretend to) MF COBOL. I suspect they are the culprit. Regards, Tim
939.4	odump on only the executable ?	CICS03::helen	Helen Pratt	`Fri May 09 1997 03:32`	14
	Tim, I'll get the customer to do an odump -Pv against the cicsas executable next time they see the problem. However just one quick thought - the cicsas executable utilises multiple CICS specific shared objects. Is odump -Pv on the executable going to be useful without the same information on the shared libraries? Thanks, Helen.