Digital Art Zone

What kind of tools and techniques do folks use for debugging DAZ SDK plugins?  I’m an experienced Java programmer but am relatively new to C++, and unfortunately I’m not finding many of the tools I’ve grown to rely on in Java—most notably, informative stack traces. 

I’m running Visual Studio 2012 (also new to this, usually just an Eclipse guy) and Daz Studio 4.5 64bit.  For some reason I can’t get the debug configuration of my plugin to build—error is “LINK : fatal error LNK1181: cannot open input file ‘QtCored4.lib’”.  I imagine I need to drop in a debug version of some Qt library, but some guidance on this would be very helpful. 

Beyond that, how do I go about identifying the offending line of code when I experience a hard crash in my plugin?  The Daz crash error dialog’s stack trace typically isn’t of much use, and often doesn’t even come up during a crash.  Most of my problems thus far have been due to null- or uninitialized pointers, and can be painfully slow to identify if you are relying on manually stepping through code by littering it with debug print statements. 

Any guidance is much appreciated!

Thanks
Ivan

Moved to the SDK forum - Developer Discussions is for DAZ Script.

shoei321 - 22 November 2012 06:40 PM

What kind of tools and techniques do folks use for debugging DAZ SDK plugins?  I’m an experienced Java programmer but am relatively new to C++, and unfortunately I’m not finding many of the tools I’ve grown to rely on in Java—most notably, informative stack traces. 

I’m running Visual Studio 2012 (also new to this, usually just an Eclipse guy) and Daz Studio 4.5 64bit.  For some reason I can’t get the debug configuration of my plugin to build—error is “LINK : fatal error LNK1181: cannot open input file ‘QtCored4.lib’”.  I imagine I need to drop in a debug version of some Qt library, but some guidance on this would be very helpful. 

Beyond that, how do I go about identifying the offending line of code when I experience a hard crash in my plugin?  The Daz crash error dialog’s stack trace typically isn’t of much use, and often doesn’t even come up during a crash.  Most of my problems thus far have been due to null- or uninitialized pointers, and can be painfully slow to identify if you are relying on manually stepping through code by littering it with debug print statements. 

Any guidance is much appreciated!

Thanks
Ivan

This is an oversight on DAZ’s part.  You can delete the x64 configuration and recreate it from win32 or simple change the libraries that Debug x64 links against be the same as release.  Or just remove all the d’s so that the libraries it links against look like
- dzcore.lib;QtCore4.lib;QtGui4.lib;Qt3Support4.lib;opengl32.lib;QtScript4.lib

Ok thanks, got the x64 debug config to build now.    Can you give me any guidance on how to get the Visual Studio debugger to work with Daz Studio, as far as setting breakpoints etc?

Thanks

Should have been a bit more specific in my follow-on question…

I have pointed the VS debugger at the DazStudio executable and it fires it up when I launch the debugger, but i get a warning “No Debugging Information ... Cannot find or open the PDB file”.  I have my project creating a PDB file for the plugin but i don’t see where/how to point the debugger at it. 

thanks

Uhhh
- click somewhere in your code
- hit F9
- hit F5 to run in debug mode(it is going to tell you it can’t launch your dll) so you are going to want to set the Project -> Properties -> Debugging -> Command to be the daz studio executable.

shoei321 - 26 November 2012 03:16 PM

Ok thanks, got the x64 debug config to build now.    Can you give me any guidance on how to get the Visual Studio debugger to work with Daz Studio, as far as setting breakpoints etc?

Thanks

I find that the easiest way to debug a plugin is to use the “Attach to process” option from Visual Studio (it’s in the Debug menu).

You just need to have some sort of “start the plugin button” to give you time to do this small manual step.

Basically the work-flow (for me at least) is:

Build the plugin dll.
Shut down DAZ Stuido if running.
Make sure it is copied to <DAZ studio installation >/plugins. Either do this manually or set the the build options to do it for you.
Start up DAZ and attach the debugger to the DAZ studio program thread.
Start the plugin.

This allows you to set break points and do all the normal debugging things, like reading content of data structures and such like

Using F5 to run the plugin from Visual Studio will not work, unless you are building a stand-alone program.

say what? lol.  hmmmm…

Apparently a very old message and so hopefully resolved, but also getting caught back up myself after a long hiatus.

Just that there isn’t many messages in this forum and I would HATE to see someone new scroll down and start reading posts to get caught up, (or even started,) read this, and actually believe it! eeeek! In fact, the reason I read it was because I’d been away for 8 months, and thought I’d just start at the mid-to-bottom of the “first” page…

Except for the dtamm answer, which should be believed…

1) If new to C++, then learning the available tools (and jargon,) will certainly be helpful. The tools are: Debugger.

After that, you have all the various variable viewing options, breakpoints, CallStack viewing (if that is what Java dev’s refer to as a stack dump?)

a) set the code to build with debug info
b) build and run it (in debug mode)
c) if it crashes, it WILL tell you. and where. scroll up a few lines, set a break-point, STOP the run, restart, make sure the var’s Auto tab is open, step up carefully up to the point it is going to crash… fix the error…
d) null and/or un-initialized pointers are a HUGE part of switching from a pre-managed language like JAVA or BASIC. People get lazy about setting var types and values because the language does it for them. That is why they were invented. But C++ isn’t that caring - it assumes you “meant” to do that… You “meant” to not waste time initializing it; you meant to create a char array and willy-nilly drop 4-byte floats in by in [index], and hence step on yourself…

2) You can of COURSE use F5 to step into debugging a plugin built against a release/public build of Studio…phhhffft! That’s how EVERYONE does it. Including the DAZ dev’s - they may or may not have a current Debug build open, because, for example, they may have a plugin that runs fine under Debug Studio, but crashes under Release build. So they REQUIRE a local release build of Studio, and only the plugin can switch between debug or release. That’s my “wild” guess about why even DAZ dev’s would need to do it anyways - fanciful, but still at least believable.

In any event, I have been using F5 to run a debug version of my plugins against a release build of Studio since DS was 2.x, and MS VC++ was 6.0… so like, last century…

Shoie: hopefully you didn’t give up? been 4+ months I guess…

If you haven’t, I can definately help you out getting C++ familiar if you like. Debugging side especially, since I’m a bit of a “sloppy” coder myself. IM and all that. Will get you going though, and always around.

If you did give up on the C++, try out Scripting! Serious. 100% a super-set of JavaScript. You of course have to learn the names of Studio ...thingy’s… (Whatever JAVA people call classes, plugins, functions, etc.)

Studio Scripting is totally same language as JavaScript people are used to though. It is built on top of QtScript, which is built on top of QtJavaScript…