How to generate the Symbols file of a PowerBuilder program for dump analysis?
Are you running into a problem with a compiled PowerBuilder application?
I've never used the Microsoft debugger, however, I have used Dependency Walker and ran my app from within that environment. Usually that helps us if we have missing deployables, etc.
If you need a stack dump, have you thought about running the app from the Run window and adding the /debug option after the name of the app? That creates a call stack log that shows all your commands being called, etc. Probably would get you what you need.
Please advise.
You can install Dr. Watson (drwtsn32) to automatically create a crash dump when/if your application dies.
That said, the dump will usually only be useful if you are calling into native DLL's. Otherwise the stack will just include various PBVM calls that will be difficult to correlate back to actual source code lines.
Related
I am trying to use an application called CLUT.exe which is an old application for MS-DOS that can be used to reindex NTX files for DBF databases.
(This is not the main topic, but I am just writing this if someone wants to test the app and don't trust at all about the content).
The problem starts when trying to run the command line version through console (cmd.exe) and this error appears:
C:\>CLUT.exe [arg1] [arg2] [arg3]
run-time error R6009
- not enough space for environment
So, according to what I've searched, this could be a possible solution:
http://support.microsoft.com/default.aspx?scid=kb;en-us;230205
but it doesn't work and every alternative that I found to solve this over the internet is the same.
Another alternative could be to make right-click in the .exe file, go to Properties then Memory tab and increase the Initial environment memory from Auto to the max value but it doesn't work too.
Well, I am stuck and no "possible" solution is working for me. If someone is interested, knows more about this issue and want to test, you can download the application from here (click "Free Download" green button):
http://www.filebasket.com/free/Development-Clipper-programming-language/clut-exe/13996.html
or directly from my DropBox:
https://dl.dropbox.com/u/15208254/stackoverflow/clut_214.rar
Just to know, I am using Windows 7 and the CLUT.exe application is a Clipper based app (old programming language) that may run under windows console (cmd.exe).
Wikipedia does mention other dos emulators but, oddly, doesn't mention BOCHS.
Reindexing NTX files is not a difficult thing to do, and can be done with tools other than CLUT. For example, many of the utilities listed on this part of Download32 could be used. Otherwise, you could write your own using Harbour Project or xHarbour. Or contact me off list and I'll cook up something in Clipper 5.3.
LATER
If I read the README correctly for CLUT, it's a replacement for the DBU utility that comes with Clipper 5.x. I can supply you with a build of that if you're unsuccessful with other approaches.
I've done some search out there but couldn't find too much really helpful info on it, but could someone try to explain the basic of Java memory maps? Like where/how to use it, it's purpose, and maybe some syntax examples (inputs/outputs types)? I'm taking a Java test soon and this could be one of the topics, but through all of my tutorials Jmap has not come up. Thanks in advance
Edit: I'm referring to the tool: jmap
I would read the man page you have referenced.
jmap prints shared object memory maps or heap memory details of a given process or core file or a remote debug server.
NOTE: This utility is unsupported and may or may not be available in future versions of the JDK. In Windows Systems where dbgeng.dll is not present, 'Debugging Tools For Windows' needs to be installed to have these tools working. Also, PATH environment variable should contain the location of jvm.dll used by the target process or the location from which the Crash Dump file was produced.
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jmap.html
Its not a tool to be played with lightly. You need a good profiler which can read it output as jhat is only useful for trivial programs. (YourKit works just fine for 1+ GB heaps)
My company has a program that uses Lua embedded in its runtime, loading up .lua files from disk and executing functions defined in them repeatedly.
Is there a way to attach to the running process and set breakpoints in my .lua files? (I'd accept either gdb-style command-line debugging as part of the Lua distribution, or perhaps a third-party IDE that provides Visual-Studio-like GUI breakpoints.)
Or is what I'm asking for entirely nonsensical and impossible given the nature of the runtime loading up random files from disk?
Edit: Looks like it's not nonsensical, given that Lua's own debug.getinfo() function can determine the source file for a given function, and debug.sethook() allows a callback for each new line of code entered. So, it's reasonable to load source code from disk and be able to tell when the interpreter is executing a particular line of code from that file. The question remains: how do I latch onto an existing process that has a Lua interpreter and inject my own trace function (which can then watch for file/line number pairs and pause execution)?
If you can modify the .lua files, you can insert the following call just before anything you need to debug:
require 'remdebug.engine'.start()
It starts the RemDebug Lua debugger engine and tries to connect to a controller. If it cannot connect, it will just continue running as normal. I did some fixes to the debugger engine, such as dealing with temporary variables, and my student is working on a debugger GUI (due next year).
In the meantime, you can try if Lua Development Tools works for you. It features a debugger similar to RemDebug, which should be possible to set up as follows:
require("debugger")(host, port, idekey)
Alternatively, you can use SciTE-debug, which is an extension to the SciTE editor, and can serve as a controller to RemDebug. Just make sure you insert the call to remdebug.engine.start somewhere in your Lua code and insert this into the SciTE output window:
:debug.target=remote.lua
When you start your program, SciTE should show the source and current line.
I've been using Decoda editor for that. It allows you to attach to a running C++ application, after that it detects that you're running a Lua Interpreter within your C++ code and show your Lua source code, where you can add beakpoints and inspect variables as usual.
This is an alternative I use after much searching. If you have an external executable that loads lua, I got this working in a few minutes. The op is very responsive, it has an interactive debugger which loads your code you can place debug points interactively. It doesn't have an editor, but I use scite or crimson editor and start the executable, one line in your main lua module enables the debugger.
http://www.cushy-code.com/grld/ - this link seems dead now
I've moved to eclipse.org/ldt it has an ide and integrated debugger, recommended
hth
The Lua plugin for IntelliJ has a working debugger with no special setup required other than pointing to your Lua interpreter.
Here's a screencast of it:
http://www.screencast.com/t/CBWIkoZPg
Similar to what Michal Kottman described, I have implemented a debugger based on RemDebug, but with additional fixes and features (on github: https://github.com/pkulchenko/MobDebug).
You can update your .lua file with require("mobdebug").start("localhost", 8171) at the point where you want the debugging to start. You can then use the command line debugger to execute commands, set breakpoints, evaluate/execute expressions and so on.
As an alternative, you can use ZeroBrane Studio IDE, which integrates with the debugger and gives you a front-end to load your code and execute same debugger commands in a nice GUI. If you want to see the IDE in action, I have a simple demo here: http://notebook.kulchenko.com/zerobrane/live-coding-in-lua-bret-victor-style.
You should probably use Decoda.
Go to Debug -> Processes -> Attach to attach your process. This should work fine.
Well the easiest way is this, thanks to the genius author
https://github.com/slembcke/debugger.lua
you don't need to setup a remote debug server ,just require one file,and simplely call dbg() and it will pause,just like gdb
an tutorial is also shipped with it, check it out.
I am attempting to use WinDBG or another debugger to debug a CodeGear Delphi 2007 Windows application on a remote machine. I have been unable to produce symbol files for WinDBG.
Is there a way to use WinDBG or another debugger to debug Delphi applications on a system that doesn't include the IDE?
Edit1
The remote debugger is not an option here. I am able to remote in to the end user PC, but I am unable to use the remote debugger due to firewall restrictions.
Edit2
I am able to remote in to the machine, but can not connect the CodeGear remote debugger due to firewall restrictions.
How about the remote debugger? Build your app with remote debug symbols and debug from your development machine across the network.
instead, i rely on MadExcept stack tracing and some logging features. my application is distributed worldwide & this has been sufficient.
You can try generating a map file and then convert it to a dbg file using map2dbg from
http://code.google.com/p/map2dbg/
Then you can load the dbg file in WinDbg.
Disclaimer: I had faced a similar issue but I managed to do remote debugging and didn't have to do all this. So I am not sure this will work. But if you try it then do let us know if it works.
I'm afraid this is one more of those "I don't have an actual answer" answers, but it might just help...
Have you considered adding logging to your application? I've heard great things about SmartInspect. With it, you can log all sorts of information, including stack traces and "watches" (variables).
Another logging product for Delphi is EurekaLog.
In Delphi you could use Run -> Attach to Process, select the remote machine and select the process you'd like to debug.
http://sourceforge.net/projects/tds2dbg/ can be used to convert Delphi's TDS debug files to DBG files. This gives basic symbol information -- functions, classes, units, but not variables. Enough for a reasonable call stack, and with a bit of knowledge, enough to debug Delphi apps live and with dumps.
I've written about some of Delphi+WinDBG experiences on my blog: https://marc.durdin.net/2015/11/windbg-and-delphi-a-collection-of-posts/
Thank you all for the great suggestions and interesting products.
To solve this specific issue, the "best" way I found uses the OutputDebugString located in the Windows namespace. This, along with Debug View from Sysinternals, will allow me to gather debug information and sort through it pretty quickly.
If you decide to use this method, make sure everything is wrapped in ANSI formatting. IE:
OutputDebugString(PAnsiChar(string1 + string2));
This makes sure that string1 and string2 are combined and then converted in to ANSI Characters.
I probably should have just started dumping text to a file for something quick and dirty, but this will allow a non-debugging version to emit debugging messages.
I'm finishing an internship at a company and have just been thrown onto this project for the last month where the program is built upon an engine that they "failed" to buy the source code for. Now I've been given the task of finding out why it is failing, on only certain conditions and customer feedback hasn't been great. The main developer for the project is also out on leave for several months.
I have the engine install and know the language it was written in (delphi6?).
note which I have never had to use
I have our products msi.
I'm expected to go through the regular app and pinpoint the problem. I suspect it is something to do with fields not being re-initialized properly.
Is there a way to attach a debugger to the exe to see callstacks and all that hotness?
Any help that would avoid countless use cases would be received gratefully.
You can attach the Delphi debugger to any running process (like all other win32 debuggers out there) but I don't think the experience will be near what you expect. Delphi produces really tight executables which means the info for building human readable callstacks or any kind of "hotness" are simply not there.
Your only chance is in that if your application is a Debug release. In that case, Delphi debugger should help more than a generic debugger.
You might also want to have a look at this thread - Is there a program to decompile Delphi?
In Delphi 2006 (not sure about 6) you can attach the debugger to a running process.
You only get assembler instructions, registers, flags, memory dump and stack (hex). Hope that is enough.
Nice, I tried to attach to the ide/debugger and they disallowed that ;-).