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

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9120.0. "DU V4.0b and valloc" by DEKVC::JUNMOKSONG () Tue Mar 11 1997 21:38

	Hi,
    
        I noted this on DEC C conference too. 
    
	My customer have thread program which ran O.K on DU V3.* but
	after upgrading DU to V4.0B, the following error happened.
        It is same error regardless of using malloc or valloc.

	1. I applied all patch file for DU V4.0B up to FEB 22 '97.
	2. The compile option 
	   $cc -g -c -pthread -I../inc -I/data2/tmroutine/inc -I -I
            -O2 -Olimit 4500 -std1 -DOSF1 -DA_OSF -Wf -readonly_strings 
            -D_INTRINSICS -I/data1/oracle/app/oracle/product/7.3.2/ddbms/demo
	3. The link option
	   $cc -g -Olimit 4500 -o ../bin/convoy ..... -L/data1/oracle/product/
            7.3.2/precomp/lib -L ..... -lmach -lexc -lc -lpthread 
            -L/usr/lib/usr/lib/libc.a -lm -lC
	 4. The trace of dbx 

	  dbx>
	 >0 (unknown)() [0x3ff80193110]
	  1 (unknown)() [0x3ff80194534]
	  2 _valloc(0x3ffc008ae28,0x3ffc008a21b,0x12007c79c,0x1400241d8,
                    0x140a7228e)[0x3ff801930ac]
          3 ut_combat_system_point(.......)
	  4 ut_COMBAT_SYSTEMS_POINTER(......)  
	  5 integerize_Unit_Combat_Arrays(......)
 	  6 Balance_TOE_Vs_On_Hand(......)
	  7 Update_Unit_Vehicles(......)
	  8 Assemble_Vehicles_At_Home_Unit_State(......)
 	  9 Supply_Run_Mission(......)
	 10 Craete_And_Assign_SRM_Attributes(......)

	 My question is 

	 What is the "unknown" function? and how can I debug thread program?
	 Can anyone tell me the clue about this program?

         In advance, thank you so much.
	 Best Regards,
 	 Jun-Mok Song
T.RTitleUserPersonal
Name		DateLines
9120.1try ladebug...QUARRY::petertrigidly defined areas of doubt and uncertaintyWed Mar 12 1997 11:0014
For thread programs on V4.0B, you should be using ladebug, which is delivered
on the base system.  Ladebug has a better interface to threads than dbx
does, and can give you more detailed information.  As for what the 'unknown'
routines are, I would hazard a guess that sbrk is one of them, and 
some intermediate code for the other.  They are showing up as unknown
because they are coming from a library which is stripped of symbol table info.
Or at least partially stripped.  Without any real information about what
the routines might be, dbx is here just showing that there are discreet 
routines which are at the particular pc's at the time of the crash.
I'm sure some more thread knowledgable people will pop in to give you a 
better guess as to what might be causing the problem, as that's about
as much as I can tell you.

PeterT
9120.2What was the error??WTFN::SCALESDespair is appropriate and inevitable.Wed Mar 12 1997 13:479
Actually, the "unknown" routines are probably the thread-safe library support
routines, which usually seem to show up that way (because they are called via
pointers?).

What is the nature of the error?  (I.e., you say an error happened, but you
don't give any indication of what it was...)


				Webb
9120.3More info.DEKVC::JUNMOKSONGWed Mar 12 1997 20:176
    Hi,
    The program is hung of program. On previous version that program was
    O.K but on V4.0B the program was hung and when I sow the trace, the
    unknown is displayed.
    Best Regards,
    Jun-Mok Song
9120.4OK, which kind of "hung"?WTFN::SCALESDespair is appropriate and inevitable.Thu Mar 13 1997 11:509
.3> The program is hung of program.

Is it blocked (i.e., consuming no CPU time at all), or is it spinning ((i.e.,
consuming all available CPU time)?

What does Ladebug show that the other threads (if any) doing?


				Webb