LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Lost of debugger control

Hello all,

I've been hunting a bug for the last 24 hours and I need some help !
I suspect it's some kind of pointer problem, but...
It's a CVI program that runs both on Windows and Linux. I use full debug
options in both cases and lots of printf.

When I step in the debugger it more or less fails in the same area (but not
exactly the same). The CVI IDE becomes unresponsive (pressing [Stop] doesn't
do anything), my own UIR is unresponsive. The only thing that brings it back
is pressing Ctrl-C in the console window. But then I've noticed that the IDE
becomes a bit inconsistent (for instance if I change project within the same
workspace, it won't link showing errors belonging to the other project !).

Now if I run the same program under Linux, it seems to run properly, but
when I exit the program, I get a core dump at the very end. Running it in
Valgrind to track down errant pointers didn't help (it finds some [minor?]
problems in libraries, but nothing in my prog).

Does the errant behavior of the freezing IDE ring a bell for someone ? I
could use any info, thanks.
--
Guillaume Dargaud
http://www.gdargaud.net/
"Kids, you tried your best, and you failed miserably. The lesson is, never
try." - Homer Simpson.


0 Kudos
Message 1 of 7
(3,410 Views)
I proofread the message, but obviously not the subject, it should have been
"Loss of debugger control" !
--
Guillaume Dargaud
http://www.gdargaud.net/
"I hated going to weddings. All the grandmas would poke me saying 'You're
next'. They stopped that when I started doing it to them at funerals."
scirDSL.


0 Kudos
Message 2 of 7
(3,410 Views)
In addition, if I enable the global break key and I press it while the IDE
is deadlocked, CVI and my app die instantly... I know this isn't supposed to
happen but are there circumstances where it's been observed ?

I can't retrace my steps back because I spent the last several days
refactoring my code (thousands of line changes)...

Shouldn't I get at least something in the event log ? A DrWatson report or
something ?!?
--
Guillaume Dargaud
http://www.gdargaud.net/


0 Kudos
Message 3 of 7
(3,396 Views)

I had similar problems debbugging under windows. The only way i found to solve the problem is to make the following setting:

BuildOptions--> DebuggingLevel --> No run-time checking

 

Jochen

0 Kudos
Message 4 of 7
(3,380 Views)
>I had similar problems debbugging under windows. The only way i found to
>solve the
> problem is to make the following setting:BuildOptions-->
> DebuggingLevel -->
> No run-time checking Jochen
Hmmm, a bit counter-intuitive... In order to find a runtime error, you have
to disable runtime checking...

Anyway, I think I found the error:
using a variable argument function and then passing said variable arguments
onto vfprintf... But one of the calls had one more arguments than there were
'%' in the format string. It was nasty as hell to find because it caused
errors in random parts of the program.

Just to say that CVI can spot this kind of problem at runtime if it happens
in printf, but not apparently if it happens in vfprintf. Maybe it could be
added in the future (I have no idea if the inner workings of both functions
are the same).

All this could probably have been avoided if there'd been an absolutely
necessary vfnprintf function(maybe it's been added in 9.0, I'm still with
8.0/8.5).
--
Guillaume Dargaud
http://www.gdargaud.net/


0 Kudos
Message 5 of 7
(3,370 Views)

Surely passing extra arguments simply means they will be ignored? Even passing too few arguments should (usually) only cause garbage strings to be produced, not program crashes.

 

JR

0 Kudos
Message 6 of 7
(3,366 Views)
> Surely passing extra arguments simply means they will be ignored? Even
> passing too
> few arguments should (usually) only cause garbage strings to be produced,
> not
> program crashes. JR
Well, the deadlock problem seems to be gone now...
--
Guillaume Dargaud
http://www.gdargaud.net/


0 Kudos
Message 7 of 7
(3,359 Views)