LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

debugger ignoring SetBreakOnLibraryErrors

OK, what am I missing here?

 

I have these two lines of code in a function:

 

	SetBreakOnLibraryErrors(0);
	rc = ClientTCPRead (g_hconversation, l_p, n, d);

 And...I just got a break in the debugger:

 

NON-FATAL RUN-TIME ERROR: "tcpsupport.c", line 142, col 10, thread id 0x000029E4: Library function error (return value == -11 [0xfffffff5]). Timeout error

 

What gives?

0 Kudos
Message 1 of 12
(4,188 Views)

Hi mzimmers,

 

It looks like the TCP read is timing out - it doesn't get any data in d ms.

Humphrey H.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 12
(4,175 Views)

Hi, Humphrey -

 

I should have been more specific in my question: I realize the error is a timeout. What I was wondering is, why am I breaking on this error, when I've explicitly disabled breaks on library errors in the line of code just before the read?

0 Kudos
Message 3 of 12
(4,176 Views)

I believe I discovered the problem. Somehow, I had selected Run->Break On->Library Errors, and evidently this setting overrides the programmatic control. (Please correct me if I'm wrong.)

 

Thanks for looking, and sorry for the red herring.

 

EDIT: no, that wasn't it. I just made sure I hadn't selected the above option, and I STILL got a break. Possible bug?

0 Kudos
Message 4 of 12
(4,171 Views)

Hey mzimmmers,

 

I just tried this function, and it worked properly for me. I had to include utility.h, and then if I call SetBreakOnLibraryErrors(0)   right before the ClientTCPRead call, I do not get an error popup. To clarify, are you seeing the popup box with the error, or does it just show up at the bottom of the screen?

0 Kudos
Message 5 of 12
(4,143 Views)

I just tried it out and it seems to be working. Having Run»Break On»Library Errors selected should not be a problem as SetBreakOnLibraryErrors is used to temporarily disable that setting. Check that run-time checking is not disabled. Run-time checking is enabled when you set the debugging level in the Build Options dialog box of the Workspace window to Standard or Extended, and select a debug configuration.

 

 

Humphrey H.
Applications Engineer
National Instruments
0 Kudos
Message 6 of 12
(4,140 Views)

Humphrey: do I understand you that, if the build configuration is set for debug, and if the level is "standard," then the programmatic call is essentially ignored? That would explain what I'm seeing.

 

Daniel: it's from memory, but I'm pretty sure I was getting the pop-up box as well.

 

Thanks.

0 Kudos
Message 7 of 12
(4,132 Views)

According to  this thread SetBreakOnLibraryErrors supersedes the menu item...

0 Kudos
Message 8 of 12
(4,124 Views)

Yes, it seems to supersede the menu setting, but not necessarily the build options setting in the configurations dialog.

 

I know I'm just a newbie here, but I think the CVI team could have made this a bit less complicated.

0 Kudos
Message 9 of 12
(4,116 Views)

It should work properly if the Build configuration is Debug and the Debugging Level in Build Options»Debugging Options is Standard or Extended. SetBreakOnLibraryErrors will have no effect if run time checking is disabled (see the section before Example code here: http://zone.ni.com/reference/en-XX/help/370051V-01/cvi/libref/cvisetbreakonlibraryerrors/). 

Humphrey H.
Applications Engineer
National Instruments
0 Kudos
Message 10 of 12
(4,110 Views)