Every time I add debugging code it works perfectly: every time I remove
it, it stops working....

I think I'm going to watch TV instead.

--
"Women actually are capable of being far more than the feminists will
let them."

The Natural Philosopher wrote:

> Every time I add debugging code it works perfectly: every time I remove
> it, it stops working....

The lesser spotted heisenbug

On 08/08/2023 18:35, The Natural Philosopher wrote:
> Every time I add debugging code it works perfectly: every time I remove
> it, it stops working....
>
> I think I'm going to watch TV instead.

Try changing the order in which variables are declared - perhaps you're
overwriting something? Or something like that?
--
Cheers,
David
Web: https://www.satsignal.eu

On 08 Aug 2023 at 18:35:51 BST, "The Natural Philosopher"
<tnp@invalid.invalid> wrote:

> Every time I add debugging code it works perfectly: every time I remove
> it, it stops working....

I once earwigged on a conversation at CERN between a physicist and someone in
the Program Enquiry Office, where users could go to get help with their
programs. The physicist reported similar symptoms to you, and of course it
turmned out that his conditional GOTO which was intended to skip the debugging
statements, was skipping a big chunk of that particular subroutine.

--
Tim

On Tue, 8 Aug 2023 18:35:51 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> Every time I add debugging code it works perfectly: every time I remove
> it, it stops working....

Many years ago a colleague of mine had one of those that he was
able to pin down to a bug in the register use tracking in that particular
compiler (MS supplied IIRC). In the end the production code had a call out
to a function that did nothing just to force the compiler to behave.

> I think I'm going to watch TV instead.

Yeah - you probably have an access beyond bounds problem - have fun
finding it.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 8/8/23 14:43, Ahem A Rivet's Shot wrote:
>
> Yeah - you probably have an access beyond bounds problem - have fun
> finding it.
>
Another possibility is a timing problem. Debug code can slow things down
enough to change a race condition.

The Natural Philosopher <tnp@invalid.invalid> wrote:
> Every time I add debugging code it works perfectly: every time I remove
> it, it stops working....

You could also try Gdb on the version with the debugging code
turned off. But building with Gdb support enabled can change
program behaviour too. I found it wasn't friendly with (direct)
GPIO operations on the Pi Zero and things only worked sensibly
without it.

--
__ __
#_ < |\| |< _#

On a sunny day (Tue, 8 Aug 2023 18:35:51 +0100) it happened The Natural
Philosopher <tnp@invalid.invalid> wrote in <uatudn$3g3qj$3@dont-email.me>:

>Every time I add debugging code it works perfectly: every time I remove
>it, it stops working....

Depends
I never use debuggiging code whatver that is
but every subroutine routine I write starts like this:

int connect_to_news_server(char *server, int port)
{ struct hostent *hp;
struct sockaddr_in sa; /* -Wall gets confused */
int a, i;
char temp[TEMP_SIZE];
char dotted_quad[TEMP_SIZE];
int flags;
time_t connect_timer;
extern int idle_cb();
int connect_flag;
unsigned long in;
int byname;

if(debug_flag)
{
fprintf(stdout, "connect_to_news_server(): arg server=%s port=%d\n",\
server, port);
}

/* argument check */
if(! server) return(0);
if(port <= 0) return(0);

So if I specify -v on the command line that sets 'debug_flag' and shows what is happening everywhere
If I just comment out the 'if(debug_flag)' it shows what's happening with / in that specific
routine.
If -v specified then with any argument error it wil exit with the last routine where it failed
Usually only takes a second to find a fault.

>I think I'm going to watch TV instead.

Yea but no football today?

>--
>"Women actually are capable of being far more than the feminists will
>let them."
>
>
>

On 08/08/2023 18:35, The Natural Philosopher wrote:
> Every time I add debugging code it works perfectly: every time I remove
> it, it stops working....
>
> I think I'm going to watch TV instead.
>

I try to make debug code part of the standard build, configurable at
runtime, e.g. loggers etc, is there a log4C? There is!

You might still have the same problem, but at least it is easier to switch.

On 09/08/2023 06:41, Jan Panteltje wrote:
> On a sunny day (Tue, 8 Aug 2023 18:35:51 +0100) it happened The Natural
> Philosopher <tnp@invalid.invalid> wrote in <uatudn$3g3qj$3@dont-email.me>:
>
>> Every time I add debugging code it works perfectly: every time I remove
>> it, it stops working....
>
> Depends
> I never use debuggiging code whatver that is
> but every subroutine routine I write starts like this:
>
> int connect_to_news_server(char *server, int port)
> {
> struct hostent *hp;
> struct sockaddr_in sa; /* -Wall gets confused */
> int a, i;
> char temp[TEMP_SIZE];
> char dotted_quad[TEMP_SIZE];
> int flags;
> time_t connect_timer;
> extern int idle_cb();
> int connect_flag;
> unsigned long in;
> int byname;
>
> if(debug_flag)
> {
> fprintf(stdout, "connect_to_news_server(): arg server=%s port=%d\n",\
> server, port);
> }
>
> /* argument check */
> if(! server) return(0);
> if(port <= 0) return(0);
>
>
> So if I specify -v on the command line that sets 'debug_flag' and shows what is happening everywhere
> If I just comment out the 'if(debug_flag)' it shows what's happening with / in that specific
> routine.
> If -v specified then with any argument error it wil exit with the last routine where it failed
> Usually only takes a second to find a fault.
>

Sorry, I should have read your post before I posted mine. I made the
same kind of point. Diagnostics should be permanent.

Although, what you are suggesting looks a bit like a verbose version of
ASSERT. Which can cause problems. In general, I prefer loggers.

On 08/08/2023 18:43, Andy Burns wrote:
> The Natural Philosopher wrote:
>
>> Every time I add debugging code it works perfectly: every time I
>> remove it, it stops working....
>
> The lesser spotted heisenbug
>
Murphy at work.

--
"It is an established fact to 97% confidence limits that left wing
conspirators see right wing conspiracies everywhere"

On 08/08/2023 18:45, David Taylor wrote:
> On 08/08/2023 18:35, The Natural Philosopher wrote:
>> Every time I add debugging code it works perfectly: every time I remove
>> it, it stops working....
>>
>> I think I'm going to watch TV instead.
>
> Try changing the order in which variables are declared - perhaps you're
> overwriting something?  Or something like that?

Well obviously something utterly stupid is going on, and I still don't
feel very intelligent yet. More coffee may encourage me to look. It is
quite complex with about a dozen variables being compared to arrive at a
single state change.

--
"It is an established fact to 97% confidence limits that left wing
conspirators see right wing conspiracies everywhere"

On 08/08/2023 18:54, TimS wrote:
> On 08 Aug 2023 at 18:35:51 BST, "The Natural Philosopher"
> <tnp@invalid.invalid> wrote:
>
>> Every time I add debugging code it works perfectly: every time I remove
>> it, it stops working....
>
> I once earwigged on a conversation at CERN between a physicist and someone in
> the Program Enquiry Office, where users could go to get help with their
> programs. The physicist reported similar symptoms to you, and of course it
> turmned out that his conditional GOTO which was intended to skip the debugging
> statements, was skipping a big chunk of that particular subroutine.
>
Could be I deleted something else than the debug statements. Which was a
massive printf printing out everything..

--
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

On 08/08/2023 20:43, Ahem A Rivet's Shot wrote:
> On Tue, 8 Aug 2023 18:35:51 +0100
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> Every time I add debugging code it works perfectly: every time I remove
>> it, it stops working....
>
> Many years ago a colleague of mine had one of those that he was
> able to pin down to a bug in the register use tracking in that particular
> compiler (MS supplied IIRC). In the end the production code had a call out
> to a function that did nothing just to force the compiler to behave.
>
>> I think I'm going to watch TV instead.
>
> Yeah - you probably have an access beyond bounds problem - have fun
> finding it.
>
No, its nothing like that, its is a series of complicated 'if'
conditions. It may pay me to draw a state diagram and rewrite it
completely as a state machine.

--
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

On 08/08/2023 23:10, Dennis wrote:
> On 8/8/23 14:43, Ahem A Rivet's Shot wrote:
>>
>>     Yeah - you probably have an access beyond bounds problem - have fun
>> finding it.
>>
> Another possibility is a timing problem. Debug code can slow things down
> enough to change a race condition.
>
Its really not that complicated. That's what is annoying me.

--
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

On 09/08/2023 06:41, Jan Panteltje wrote:
> On a sunny day (Tue, 8 Aug 2023 18:35:51 +0100) it happened The Natural
> Philosopher <tnp@invalid.invalid> wrote in <uatudn$3g3qj$3@dont-email.me>:
>
>> Every time I add debugging code it works perfectly: every time I remove
>> it, it stops working....
>
> Depends
> I never use debuggiging code whatver that is
> but every subroutine routine I write starts like this:
>
> int connect_to_news_server(char *server, int port)
> {
> struct hostent *hp;
> struct sockaddr_in sa; /* -Wall gets confused */
> int a, i;
> char temp[TEMP_SIZE];
> char dotted_quad[TEMP_SIZE];
> int flags;
> time_t connect_timer;
> extern int idle_cb();
> int connect_flag;
> unsigned long in;
> int byname;
>
> if(debug_flag)
> {
> fprintf(stdout, "connect_to_news_server(): arg server=%s port=%d\n",\
> server, port);
> }
>
> /* argument check */
> if(! server) return(0);
> if(port <= 0) return(0);
>
>
> So if I specify -v on the command line that sets 'debug_flag' and shows what is happening everywhere
> If I just comment out the 'if(debug_flag)' it shows what's happening with / in that specific
> routine.
> If -v specified then with any argument error it wil exit with the last routine where it failed
> Usually only takes a second to find a fault.
>
>
>
>
>
>> I think I'm going to watch TV instead.
>
> Yea but no football today?
>
>
>> --
>> "Women actually are capable of being far more than the feminists will
>> let them."
>>
>>
>>
Command line switched debug might be worthwhile in this case.

--
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

On 09/08/2023 08:03, Pancho wrote:
> On 08/08/2023 18:35, The Natural Philosopher wrote:
>> Every time I add debugging code it works perfectly: every time I
>> remove it, it stops working....
>>
>> I think I'm going to watch TV instead.
>>
>
> I try to make debug code part of the standard build, configurable at
> runtime, e.g. loggers etc, is there a log4C? There is!
>
> You might still have the same problem, but at least it is easier to switch.

Its not a program bug so much as an logical aberration, the code is
written to do a given thing, but it only does it when I print out the
variables first.

I found tow nasties already - an fopen with no fclose that leaked memory
in an infinite loop, and a value that was a default of zero if no other
value was supplied, that said you were happy if the central heating left
the room at freezing point :-)

The only true bug I ran into was a precedence thing something like
if(g=function(h) >0) where I forgot that assignment is a lower priority
than comparison...

Apart from the usual slew of syntax errors from missed
semicolons,,misspelt variable names, un-paired brackets etc. etc.

--
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

The Natural Philosopher <tnp@invalid.invalid> writes:
> The only true bug I ran into was a precedence thing something like
> if(g=function(h) >0) where I forgot that assignment is a lower
> priority than comparison...

The compiler can warn you about that one; but you do have to turn
warnings on. -Wall -Wextra is a common minimum. I usually use -Werror as
well to enforce that all warnings are cleaned up but that’s more of a
matter of taste.

$ cat t.c
int function(int);

int main(void) {
int g, h = 0;
if(g=function(h) >0)
return 0;
else
return 1;
}
$ gcc -c t.c
$ gcc -Wall -Wextra -c t.c
t.c: In function ‘main’:
t.c:5:6: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
5 | if(g=function(h) >0)
| ^

--
https://www.greenend.org.uk/rjk/

On 9.8.2023 12:41 PM, The Natural Philosopher wrote:

>> int connect_to_news_server(char *server, int port)
>> {
>> struct hostent *hp;
>> struct sockaddr_in sa; /* -Wall gets confused */
>> int a, i;
>> char temp[TEMP_SIZE];
>> char dotted_quad[TEMP_SIZE];
>> int flags;
>> time_t connect_timer;
>> extern int idle_cb();
>> int connect_flag;
>> unsigned long in;
>> int byname;
>>
>> if(debug_flag)
>>      {
>>      fprintf(stdout, "connect_to_news_server(): arg server=%s
>> port=%d\n",\
>>      server, port);
>>      }
>>

Drop the backslash from the end of thew fprintf line. It is perfectly
allowable to have whitespace between the function arguments. Whitespace
includes newlines.

--

-TV