module showing twice in debugger Variables and Call Stack window. Apparently loaded twice.

[pblase]

Ok, here's a weird one.

Just updated to LabWindows/CVI 2013, configuration report attached.

I have about a dozen different modules in the program, and one near the top of the workspace handles various configuration options, which the user can change with a nice user interface. The options are stored in a structure in memory called G_setprefs.  So far, so good.

In proper object-oriented fashion, the other modules in the program ask Preferences.c (via a call to get_G_Setprefs() )for and receive a pointer to G_setprefs if they need to read those particular configuration items. The Preferences module simply hands back "&G_setprefs" to the calling routine.  I use this methodology a lot, since this particular program uses a LOT of global data structures to pass information back and forth. The attachment "Variables 1.bmp" shows a screen dump of the Variables and Call Stack windows while the program is running. In "Global Variables (Preferences.c)" you can see "G_setprefs" at 0x008C5F10. There are also 3 other "G_" structures which are handled in much the same way. The structures store information retrieved from .ini files containing things like working directories, control preferences, and various constants. They're initialized at the program start from various .ini files.

When the program is initializing, about a dozen different modules get and receive pointers to "G_setprefs", always in the same sequence. At the second to last call, suddenly the get_G_Setprefs() routine in Preferences.c starts returning a different pointer. Nothing in particular happens between the two calls that I can see, just different modules setting up their own internals, but as you can see in Variables 2.bmp there is a second listing of "Global variables (Preferences.c)" in the Variables and Call Stack window. The first one is still there too! But now get_G_Setprefs() returns 0x00EBB600 as the pointer to G_setprefs. This second version,which I can examine in the debugger, has not been properly initialized, and has simply appeared out of nowhere. The first one is still there, and if I manually change the pointer in the routine that requested it, things work properly (among other things, it sets the color on some graph cursors).

If I examine the second listing too closely, LabWindows also crashes, as shown in "crash.gif".

Additional:

1) The problem shows up even when the program is running by iteslf, so I don't think it's the debugger, although it is compiled in debug mode.

2) Each module resides in its own dll.

[pblase]

3) I am not loading any of the modules manually, I'm letting that happen automatically.

4) This was working properly before upgrading to 2013, from LabWindows/CVI 2010.

Hmm. Apparently it is possible to load more than once copy of a dll at a time

http://digital.ni.com/public.nsf/allkb/6E1FF9F8EB5DCC0086256944004B90B0

I wonder if somehow the  dll is getting loaded twice.

[pblase]

One possible cause, which I'm exploring, is that during the build, in after-build actions, I'm copying the dll's from the source directory to a common bin directory, which is in the PATH environmental variable. I'm thinking that although the program is supposed to load dll's from the bin that the source is in first, for some reason it's loading some from the bin directory also. I'll explore further.

[pblase]

Now it's getting weird. I've double-checked all of the projects in the workspace and cleaned out any extraneous dll's.

In addition, when I run Dependency Walker on the main program, the Preferences.dll doesn't show up on the tree under the Plots.dll. (see attached). It shows up everywhere else where it's supposed to. What would mess up the dll's to be loaded?

[DJColeslaw]

Hi pblase,

Could you provide some information about the modules which are receiving the correct pointer vs. the one(s) that aren't?

Is it just the second to last call that receives the wrong pointer or does the last call receive the wrong pointer, too? If they both receive bad pointers, is it the same bad pointer?

In your last post, you mention that the Preferences.dll doesn't show up on the tree under the Plots.dll. Could you provide some more detail about what these dlls are and what you would expect to see in the dependency walker?

Thanks,

[pblase]

The subroutines that calls the G_Setprefs pointer is called in almost every other initialization routine.

"Workspace.gif" shows the workspace from LabWindows. The dlls are listed in the order of use, lower dll's call higher ones. Error Handling is called by pretty much everything, down to the main () in Level1_Main at the bottom.

Main_Init_Section contains the initialization portion of the main program. PREFS_Get_G_setprefs_ptr() is called by main() at line 7;  ANALY_Init at line 89 (L1_Analysis.); DAQHNDLR_Init() at 93 (DAQ_Handler); VOSCOPE_Init() at 105 (VOScope - above MotionControl, which the cursor is on); MCP_Init() at line 109 (MotionControl); SC_Init() at line 114 (ShutterControl); OUTGEN_Init() at line 118 (OutputGenerator); L1TEST_Init() at line 122 (L1Test); and PLOT_Init() at line 126.

Only PLOT_INIT() returns the incorrect pointer.

On closer examination - see Global Variables 2.GIF - Plots.dll loads its own copy of the Preferences dll at startup; it shows up in the window immediately. Since I don't manually load any dll's, leaving it to the .lib files included in the project (see Workspace.GIF) I can't see why this is happening.

[DJColeslaw]

Hi pblase,

There is a ton of information here and a lot going on. It would be very helpful if you could prune down your code to a functional piece that just recreates the issue and removes as much extraneous code as possible. This will allow us to troubleshoot the problem without the complication of additional interactions which don't actually affect the issue at hand.

Thanks,

[pblase]

The problem is that I don't know where to start pruning. Is it a code problem, or a problem with the link settings in LabWindows? I'm inclined to think that it's an improper setting somewhere. I'll try to see if I can get it to replicate itself in a smaller workspace.

[pblase]

Ok, I solved it - partly, and now have another problem.

Referencing Workspace 2.gif, attached, In Plots - debug.prj I had a reference to "Preferences.fp" (removed, but where the arrow points in the image) in the Instrument Files section. I made panel files for all of the dll's because it makes debugging much easier.  This was the only place where I had such an instrument files reference to one of the workspace dll's, although I do include several other NI libraries as shown. Removing the .fp files reference seems to have fixed the problem.

The new problem is that when I build the project I get the "undefined symbol" errrors shown in Build Output.txt. CFG_FileUtilities includes Plots.lib (and dll), and the "undefined symbols" are all from the NI libraries that I include: cviogl.fp and menuutil.fp. Do I need to include these in every file that includes Plots.lib?

Seems to me like your linker has issues.

[DJColeslaw]

Hi pblase,

Have you possibly changed the target type from DLL to Static Library? If so, this can cause generation of unnecessary, undefined debug symbols which can cause this "undefined symbol" behavior. Please reference the following link for information on how to fix this:

Undefined Symbol Link Error in LabWindows™/CVI™ When Building a Static Library
http://digital.ni.com/public.nsf/allkb/BF8084DB74021EE986257AB200001737

Also, try going to Build » Target Settings and make sure that "Instrument Driver Support Only" is not checked as this will cause the project to not link to the entire set of LabWindows/CVI libraries but to a smaller set of functions which can cause this error.

Thanks,