Resolve line numbers from a stack dump

I have an application with a mutex dead lock. This program is compiled with CC and the flag �g.
With pstack(pid) I get a proper stack dump with symbol names and hex addresses.
Is there any way to resolve those hex addresses to line numbers from the source file?
GNU got a tool named addr2line which solve this problem, is there any corresponding tools for Solaris 10?

Don't know about addr2line analogue (maybe you can build it on Solaris, too), but there's always an option to use dbx:
- attach to the process with 'dbx - pid'
- issue 'where' in dbx console

Similar Messages

How to get Line numbers in KVM stack traces

Hello!
I am fairly new to kvm programming and might have missed the obvious. When my program dumps a stack trace under kvm it gives me an offset (I dont know what the number corresponds to) from the method but not source line numbers like I am used to seeing under J2SE. I complie the code using -g and run it using kvm_g. For example, I see soemething like
java.lang.NullPointerException
at myclass.mymethod(+5)
at parentclass.parentmethod(+10)
Where I dont know what the +5 or +10 stand for as it relates to my source code.
Can somebody help with trying to correlate the stack trace to my source code.
Thanks.
Ranga.

I would like to know too. Has anyone found an answer?

Is it possible to obtain line numbers in the stack trace of an exception

Is it possible for e.StackTrace in the following code to contain line numbers?
try
catch(Exception e)
LogStackTrace("Stack Trace:" + e.StackTrace);}
Hong

Thank you for your response.
The linked article is for Windows Phone and it points out "it's not possible to deploy the PDB alongside the EXE/DLL". Is this also the case for Windows Store app, or Windows Store app is different and it can be deployed with a .pdb file as you
pointed out?
The Windows Store app package is like the following:
My App_1.3.0.5_AnyCPU.appxupload
It is a zip file that contains the following two files:
My App_1.3.0.5_AnyCPU.appx
My App_1.3.0.5_AnyCPU.appxsym
Hong

JSP stack trace line numbers?? used to be there?

I could have swore that JDev RC showed line numbers in JSP
stack traces?
Anyway, they'd be great. How can the JIT/ojvm be configured to
make them available to the actual .jsp line numbers.
Thanks, curt

The line numbers are there if you aren't using the jsp include tag:
<%@ include file="some.jsp" %>
Since this is a compile time include, I still feel that line numbers should be
present in the stack trace... Well, I wish they were anyway.
Thanks, curt Curt:
This depends on which JVM you are using. For 9.0.2, I believe ojvm does not give line numbers. (I think we are changing to show line numbers for 9.0.3.) If you use hospot ('java -hotspot ...') you should see the line numbers.
Thanks.
Sung

How to print line numbers in NWDS for Java?

Hi everyone,
does someone know how to print out program code with line numbers from the Netweaver Developer Studio for Java? This is inevitable for code reviews.
In Eclipse 3.4 this issue is solved. Is there possibly such a patch for NWDS as well?
Thanks,
Maria

Hi Pascal,
thanks for the quick reply. The setting you mention displays line numbers on the screen alright, but printing out does not work.
We use: SAP NetWeaver Developer Studio for SAP NetWeaver 7.1 SP06 PAT0000, Build id: 200807051938.
I guess it just does not work, because it was fixed only for Eclipse 3.4, and the above NWDS version bases on Eclipse 3.3.
What do you recommend for code inspections - copy/paste into PSPad or do you know a more comfortable practice?
Greetings
Maria

JSP compiler obfuscates generated servlet debug line numbers

          Here's something that's been baffling me for a couple of days now.
          When WebLogic parses a JSP into servlet Java source, and then compiles the Java
          source into a class, it seems to perform a further step to obfuscate debug line
          numbers in the _jspService method. This converts the debug line numbers from Java
          source code line numbers into JSP line numbers.
          At first sight, this may appear to be useful- it means that when an exception
          is thrown then it references a line number in the original JSP rather than one
          in the generated servlet. However, it actually makes life more difficult when
          you consider included JSPs.
          Suppose you have a file loginresult.jsp, which uses @include to include a header.jsp
          and footer.jsp, both of which contain dynamic content. When WebLogic converts
          line numbers, it ignores the JSP that the code came from, so this causes a many-to-one
          mapping of line numbers. When an error occurs, the exception will tell you the
          line number that it came from, but it won't tell you which JSP caused it. The
          many-to-one mapping ensures a loss of information- and no way of retrieving the
          real line numbers.
          This is an even bigger nuisance when trying to debug JSPs- the debugger hops around
          in the generated servlet file without giving any clue as to whereabouts it really
          is in the code.
          My question is: is there any way of switching off this post-processor behaviour?
          One obvious way would be to locate the WebLogic class that does this post-processing,
          stub it out and run WebLogic with this class higher up in the classpath. But that's
          a last resort.
          Secondly, would there be any other impact in turning off this behaviour? Do other
          parts of WebLogic rely on this?
          Thanks in advance,
          Kevin.


Actually, this option turns line-number table replacement on and off, for example,
          with jsp like this:
          test.jsp
          <%
          throw new Exception();
          %>
          and weblogic.xml:
          <!DOCTYPE weblogic-web-app PUBLIC "-//BEA
          Systems, Inc.//DTD Web Application 7.0//EN"
          "http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
          <weblogic-web-app>
          <jsp-descriptor>
          <jsp-param>
          <param-name>debug</param-name>
          <param-value>true</param-value>
          </jsp-param>
          </jsp-descriptor>
          </weblogic-web-app>
          the stacktrace looks like this (note line number 2 - this is JSP line number):
          java.lang.Exception
          at jsp_servlet.__test._jspService(test.jsp:2)
          at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
          at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:945)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:332)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:376)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
          at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5360)
          at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:721)
          at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3043)
          at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2468)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
          and with debug option turned off:
          <!DOCTYPE weblogic-web-app PUBLIC "-//BEA
          Systems, Inc.//DTD Web Application 7.0//EN"
          "http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
          <weblogic-web-app>
          <jsp-descriptor>
          <jsp-param>
          <param-name>debug</param-name>
          <param-value>false</param-value>
          </jsp-param>
          </jsp-descriptor>
          </weblogic-web-app>
          exception stacktrace looks like this (note that line number now is from generated .java file):
          java.lang.Exception
          at jsp_servlet.__test._jspService(__test.java:87)
          at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
          at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:945)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:332)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:376)
          at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
          at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5360)
          at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:721)
          at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3043)
          at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2468)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
          Kevin Thomas <[email protected]> wrote:
          > But this isn't useful, as you don't know which JSP the line number is referring
          > to! (did it come from the main JSP, or one of the files that it included?)
          > Turning debug off is not an answer- because that will lose other useful information
          > that is useful to the debugger.
          > Kevin.
          > "Dimitri I. Rakitine" <[email protected]> wrote:
          >>Actually, this is useful when you want to debug .jsp's and not generated
          >>..java files. Did you try setting 'debug' jsp-param in the weblogic.xml
          >>to
          >>false? I think it turns class postprocessing on and off.
          >>
          >>Kevin Thomas <[email protected]> wrote:
          >>
          >>> Here's something that's been baffling me for a couple of days now.
          >>
          >>> When WebLogic parses a JSP into servlet Java source, and then compiles
          >>the Java
          >>> source into a class, it seems to perform a further step to obfuscate
          >>debug line
          >>> numbers in the _jspService method. This converts the debug line numbers
          >>from Java
          >>> source code line numbers into JSP line numbers.
          >>
          >>> At first sight, this may appear to be useful- it means that when an
          >>exception
          >>> is thrown then it references a line number in the original JSP rather
          >>than one
          >>> in the generated servlet. However, it actually makes life more difficult
          >>when
          >>> you consider included JSPs.
          >>
          >>> Suppose you have a file loginresult.jsp, which uses @include to include
          >>a header.jsp
          >>> and footer.jsp, both of which contain dynamic content. When WebLogic
          >>converts
          >>> line numbers, it ignores the JSP that the code came from, so this causes
          >>a many-to-one
          >>> mapping of line numbers. When an error occurs, the exception will tell
          >>you the
          >>> line number that it came from, but it won't tell you which JSP caused
          >>it. The
          >>> many-to-one mapping ensures a loss of information- and no way of retrieving
          >>the
          >>> real line numbers.
          >>
          >>> This is an even bigger nuisance when trying to debug JSPs- the debugger
          >>hops around
          >>> in the generated servlet file without giving any clue as to whereabouts
          >>it really
          >>> is in the code.
          >>
          >>> My question is: is there any way of switching off this post-processor
          >>behaviour?
          >>> One obvious way would be to locate the WebLogic class that does this
          >>post-processing,
          >>> stub it out and run WebLogic with this class higher up in the classpath.
          >>But that's
          >>> a last resort.
          >>
          >>> Secondly, would there be any other impact in turning off this behaviour?
          >>Do other
          >>> parts of WebLogic rely on this?
          >>
          >>> Thanks in advance,
          >>
          >>> Kevin.
          >>
          >>--
          >>Dimitri
          >>
          Dimitri

Problems with line numbers (building via ant).

We use ant for our builds and are having a problem with getting line numbers into call stacks. When running on linux we do not get the lines for our projects (not all projects have debug option), just (Unknown Source), however we do see line numbers for the tib jars. Eclipse is fine, we can see all line numbers as appropriate.
I have tried "lines", "lines,source" and "lines,var,source" - all build a different sized jar which suggest something is getting added. However as we see line nums for tib it suggests it's some strange java runtime option. We're using sunjdk 1.5.10 and also jrockit.
Any ideas/answers most appreciated.
Many thanks, Declan
Ant task
<target name="compile" depends="init">
     <javac target="1.5" destdir="${classes}" debug="on" debuglevel="lines,source">
          <src path="${src}"/>
          <classpath refid="default.classpath"/>
     </javac>
     <javac target="1.5" destdir="${classes-test}" debug="on" debuglevel="lines,source">
          <src path="${testsrc}"/>
          <classpath refid="default.classpath"/>
          <classpath location="${classes}"/>
     </javac>
</target>
Example output
java.lang.IllegalArgumentException: Field data is null
at com.tibco.tibrv.TibrvMsg._addImpl(TibrvMsg.java:1503)
at com.tibco.tibrv.TibrvMsg.add(TibrvMsg.java:1020)
at com.lehman.fid.jdt.channel.tibrv.TibrvMessage.putObject(Unknown Source)
at com.lehman.cmd.etrading.orderbook.dp.DefaultDepthPublisher.buildSubMessage(Unknown Source)
at com.lehman.cmd.etrading.orderbook.dp.DefaultDepthPublisher.buildSubMessage(Unknown Source)
at com.lehman.cmd.etrading.orderbook.dp.DefaultDepthPublisher.publishDepth(Unknown Source)
Cmd line
VM_OPTS="-Dlogfile=../../log/CmdOrderBook.log"
VM_OPTS="${VM_OPTS} -Dcom.sun.management.jmxremote"
VM_OPTS="${VM_OPTS} -Dcom.sun.management.jmxremote.authenticate=false"
VM_OPTS="${VM_OPTS} -Dcom.sun.management.jmxremote.password=false"
VM_OPTS="${VM_OPTS} -Dcom.sun.management.jmxremote.ssl=false"
PARAMS="-springcfg orderbook-context.xml -instancename CmdOrderBook"
exec ${JAVA_HOME}/bin/java -DappInstance=CmdOrderBook -server -Xmx500M -Xms250M -Xincgc ${VM_OPTS} com.lehman.cmd.etrading.orderbook.CommoditiesOrderBook ${PARAMS} >> ../../log/Cm
dOrderBook.out 2>&1

We use ant for our builds and are having a problem with getting line numbers into call stacks. When running on linux we do not get the lines for our projects (not all projects have debug option), just (Unknown Source), however we do see line numbers for the tib jars. Eclipse is fine, we can see all line numbers as appropriate.
I have tried "lines", "lines,source" and "lines,var,source" - all build a different sized jar which suggest something is getting added. However as we see line nums for tib it suggests it's some strange java runtime option. We're using sunjdk 1.5.10 and also jrockit.
Any ideas/answers most appreciated.
Many thanks, Declan
Ant task
<target name="compile" depends="init">
     <javac target="1.5" destdir="${classes}" debug="on" debuglevel="lines,source">
          <src path="${src}"/>
          <classpath refid="default.classpath"/>
     </javac>
     <javac target="1.5" destdir="${classes-test}" debug="on" debuglevel="lines,source">
          <src path="${testsrc}"/>
          <classpath refid="default.classpath"/>
          <classpath location="${classes}"/>
     </javac>
</target>
Example output
java.lang.IllegalArgumentException: Field data is null
at com.tibco.tibrv.TibrvMsg._addImpl(TibrvMsg.java:1503)
at com.tibco.tibrv.TibrvMsg.add(TibrvMsg.java:1020)
at com.lehman.fid.jdt.channel.tibrv.TibrvMessage.putObject(Unknown Source)
at com.lehman.cmd.etrading.orderbook.dp.DefaultDepthPublisher.buildSubMessage(Unknown Source)
at com.lehman.cmd.etrading.orderbook.dp.DefaultDepthPublisher.buildSubMessage(Unknown Source)
at com.lehman.cmd.etrading.orderbook.dp.DefaultDepthPublisher.publishDepth(Unknown Source)
Cmd line
VM_OPTS="-Dlogfile=../../log/CmdOrderBook.log"
VM_OPTS="${VM_OPTS} -Dcom.sun.management.jmxremote"
VM_OPTS="${VM_OPTS} -Dcom.sun.management.jmxremote.authenticate=false"
VM_OPTS="${VM_OPTS} -Dcom.sun.management.jmxremote.password=false"
VM_OPTS="${VM_OPTS} -Dcom.sun.management.jmxremote.ssl=false"
PARAMS="-springcfg orderbook-context.xml -instancename CmdOrderBook"
exec ${JAVA_HOME}/bin/java -DappInstance=CmdOrderBook -server -Xmx500M -Xms250M -Xincgc ${VM_OPTS} com.lehman.cmd.etrading.orderbook.CommoditiesOrderBook ${PARAMS} >> ../../log/Cm
dOrderBook.out 2>&1

No line numbers in stack trace from Java Stored Procedure exception

I have a Java Stored Procedure which can generate an exception. In one database (11.1.0.6) the Java stack trace contains line numbers for my code, but not for the classes loaded by default with the JVM. In another database (same version) the Java stack trace does NOT contain line numbers for my code, but does contain them for some of the classes loaded by default with the JVM!
Neither of the schemas where I am running the the Java stored procedure has a JAVA$OPTIONS tables as described here:
http://download.oracle.com/docs/cd/B28359_01/java.111/b31225/chtwo.htm#BABIGFGA
So the Java should have been compile "-debug" by default in both schemas. I specifically set the debug option to true using:
exec dbms_java.set_compiler_option('', 'debug', 'true');
but this had no effect.
Can anyone explain this behavior or tell me how to always get line number in the Java stack trace?

Hi,
Try using java.util.logging package. Using these packages you can configure your logging information to include context down to the class name. Then each log message would be unique enough to know where it came from.
-Priyanka

Printing Line numbers while dumping stack trace during crash..

Hi,
I want to dump the stack trace of all threads with the line numbers when the program crashes. I am able to do that by cathing the signals and invoking "pstack" utility to dump the stack. But it does not dump the line numbers of each function. Is there some way of doing that?
Thanks
Atul

If you run the executable under dbx then you can type 'where' when the program crashes or set a breakpoint in your signal handler. Line numbers will only show up in the dbx stack trace if the application was compiled with -g and not stripped.

Printing from Xcode: Line Numbers ?

How can I print source from Xcode with line numbers ?

Also not a direct solution but opening your files in Text Wrangler (free version of BBEdit) will allow you to add line numbers that will print out. If you use TextMate I THINK it behaves the same as Xcode and gutter displays line numbers but doesn't print them. TextMate is so extensible there is probably a way to make it print them as well but I'm not that familiar.
=Tod
PS I am speaking of Xcode < v3 here. I've only dabbled in v3 so I can't say what may have been added.

CAS fails when subtracting negative numbers from stack

The CAS fails to subtract negative numbers. Here is how to reproduce such errors:1) generate a negative number from any operation1 - 22) subtract any number from this previous result2.1) enter any value12.2) press the subtract key, select the previous value from the stack, and copy it- (touch the previous "-1" which results from "1 - 2") (touch "copy")2.3) press ENTER Other variation:cos(-π)*ENTER*, results in -11 --1*ENTER* The issue is negative numbers are being preceded by a subtraction sign instead of a negative sign, and both are treated differently by the software. The bug does not occur in home mode.

Hello, Maké, Thank you! My report is that of a bug, not a device misuse. Particularly, a(nother) CAS bug. HP Prime's CAS is substituting binary subtraction signs for negative signs when printing results. Entering -1 in Home yedls -1, while in CAS one gets −1. See: the lengh of the dash symbol is different. Kind regards.

[svn] 688: asc: adding a barebones build. properties so we get line numbers on stack traces

Revision: 688
Author: [email protected]
Date: 2008-02-28 14:17:43 -0800 (Thu, 28 Feb 2008)
Log Message:
asc: adding a barebones build.properties so we get line numbers on stack traces
Added Paths:
flex/sdk/trunk/modules/asc/build/java/build.properties

Revision: 688
Author: [email protected]
Date: 2008-02-28 14:17:43 -0800 (Thu, 28 Feb 2008)
Log Message:
asc: adding a barebones build.properties so we get line numbers on stack traces
Added Paths:
flex/sdk/trunk/modules/asc/build/java/build.properties

Netbeans debug level - missing line numbers in stack trace

How could I set debug level to something like "lines,vars,source" in Netbeans 6.0?
I have enabled 'Generate debugging info' in project properties, but in exception stack trace aren't line numbers (only bci).
Thanks
David

Ask in a NetBeans forum, you can probably find one on java-forums.org, Java Ranch or nabble.com.
This forum's for CLDC and MIDP.
db

Stack trace gives line numbers when src is present in package hierachy?

hi,
does anyone know why the lines numbers of the source code are only given in exception traces when the source code is present alongside the class files in the package hierachy?
I'm guessing this is because there is not enough information in the class files alone?
in which case, how does it work with the source file present??
thanks,
asjf

It has nothing to do with source code files... forget that idea completely.
However, it may be something to do with your just-in-time compiler.
At runtime, HotSpot might compile the java byte code ( solely in your class file ) into native/machine code and thus lose the line number information during that internal translation.
Try running your application with the -Xint parameter for java.exe. It will turn off the Just-in-time compiler so you should
get the line number information. ( assuming you compiled the class files with javac -g )

Delete a line item from Sales Doc type RE

Unable to delete a line item from a sales order linked to document type RE. Get a long runtime - no specific error message. Use the 'Stop Transaction' option to end the transaction.
Have done thorough testing and can delete line items linked to all other sales document types in our system.
Researched SPRO to see if there was a line item deletion option that was not created for sales doc type RE - but can find nothing.
On a critical time line here - this was discovered during Hotpak installation testing which is scheduled to move to PRD June 22. Question as to why we have not run across this issue before now?? - I don't think we have had an occasion to delete a returns line item before - but I want to have the option if available.
Any help to resolve this issue would be appreciated.
Regards
Patsy

Thanks for your response.
After creating document type RE, execute VA02 transaction, select line item, select delete line item icon. The system goes into runtime and just stays there. No error message, no abap dump. To escape the transaction, I have to select 'stop transaction'.
I have tested all other document types we use in our system, (including our customized transactions) SO, CR, DR, etc., and the system allows line item deletion.

Resolve line numbers from a stack dump

Similar Messages

Maybe you are looking for