Program locks computer (DONT RUN)

Hello, I have a sketch that is locking up my mac osx (running Mavericks). I am loading the sketch onto an UNO board with an ATMEGA328p on it.

I warn you that this sketch may cause your computer to crash. Any idea why there is a problem here?

If I put all of the stuff from loop() in setup() it seems to be more stable

sketch:

#include <strippy.h>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <Arduino.h>

void setup(){
  Serial.begin(115200); // 10MHz xtal and UBRR of 0  
  Serial.write("Here we go...\n");
}

void loop() {
  uint32_t result;
  StripClass strip_object;
  result=strip_object.Function1();
  Serial.println(result);
}

Here are "strippy.cpp" and "strippy.h" respectively

#include "strippy.h"

StripClass::StripClass(){
}

uint32_t StripClass::Function1(){

    uint32_t tmp2;
    tmp2=1*Function2();

Serial.println(tmp2);
    
	return tmp2;
}

float StripClass::Function2() {

    static prog_uint32_t PROGMEM  MAX_U32=4294967200;
    float tmp=pgm_read_dword(&MAX_U32)/999999;
    
    Serial.println(tmp,2);
    return tmp;
    
}
#ifndef STRIP_H
#define STRIP_H
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <Arduino.h>
class StripClass
{

public:
	StripClass();
	uint32_t Function1();
    
private:
    float Function2();

};

#endif

Thanks in advance

So it compiles and loads and then crashes the computer?

Do you have the baud rate on the computer set correctly?

This will dump a lot of data down the serial port. Have you tried adding a delay()?

What is the code supposed to do?

And am I correct to assume it crashes your Mac but doesn't crash the Arduino?

What program is running on the Mac and communicating with the Arduino?

...R

memotick:
Hello, I have a sketch that is locking up my mac osx (running Mavericks).

Can you describe exactly what happens? I mean, what you're doing on the PC (in terms of clicking buttons in the Arduino IDE and so on), and what you see in response. At the moment I have no idea whether the problem occurs when you try to upload the sketch, or when the Arduino is running the sketch, or whether you have any clients connected to the Arduino serial port, or what you're doing with those clients.

PeterH:

memotick:
Hello, I have a sketch that is locking up my mac osx (running Mavericks).

Can you describe exactly what happens? I mean, what you're doing on the PC (in terms of clicking buttons in the Arduino IDE and so on), and what you see in response. At the moment I have no idea whether the problem occurs when you try to upload the sketch, or when the Arduino is running the sketch, or whether you have any clients connected to the Arduino serial port, or what you're doing with those clients.

Sorry everyone for the incomplete information. The computer is running the Arduino IDE and Serial monitor. When I say it crashes I mean I have to power cycle the computer as I have no control of the it (mouse, ESC, Force Quit, Nada). The sketch loads no problem on the UNO.

As far as what this program does it is a debug vehicle for a more complex program I have that is having issues. I boiled it down to the bare minimum (hence the name "stripped" :slight_smile: ) to try and isolate the problem on the larger program. I am having lots of issues with prog_uint32_t constants and am suspicious of it.

KeithRB:
So it compiles and loads and then crashes the computer?

Do you have the baud rate on the computer set correctly?

This will dump a lot of data down the serial port. Have you tried adding a delay()?

I have the baud rate of the serial monitor set correctly if that is what you mean.

The delays seem to have helped. Probably too much data down the usb cable

try uploading an example like 'blink'.
If blink crashes for computer, something else is going on.

void loop() {
  uint32_t result;
  StripClass strip_object;
  result=strip_object.Function1();
  Serial.println(result);
}

Why are you creating a new instance of the object on every pass through loop()?

It might be that the Mac is trying to buffer all the data and your disk drive is thrashing trying to VirtualMemoryize your data, this could make the computer non-responsive. How much delay did you use? I would try delay(1000).

Your version without the delay would probably overflow your arduino's buffer anyway.

Your version without the delay would probably overflow your arduino's buffer anyway.

How could it? When the outgoing buffer gets full, print(), println(), and write() block until there is room.

PaulS:

void loop() {

uint32_t result;
  StripClass strip_object;
  result=strip_object.Function1();
  Serial.println(result);
}



Why are you creating a new instance of the object on every pass through loop()?

whoa that is a good point I hadn't considered. I thought all of the variable declarations were done only once within the loop. However now that I think of it, I don't have any reason to believe this. For example, is variable "result" created each pass through the loop?

memotick:
However now that I think of it, I don't have any reason to believe this. For example, is variable "result" created each pass through the loop?

All the variables declared in the loop will be created on each iteration of the loop. But if the problem is impacting the PC and the only connection between the Arduino and the PC is that USB serial connection, I don't see how any design inefficiencies or bugs in the Arduino code can be causing the problem.

Based on your description of the behaviour you ought to see the same problem if you test a stripped-down sketch that just writes the same text sequence to the serial port. Does that produce the same problem? If not, there's something else going on between the Arduino and PC that needs to be uncovered.

PeterH:

memotick:
However now that I think of it, I don't have any reason to believe this. For example, is variable "result" created each pass through the loop?

All the variables declared in the loop will be created on each iteration of the loop.

Hmmmm. Doesn't that imply all variables used in loop must be changed global since they get reset each time the loop is iterated? I am confused. :roll_eyes:

Defining local variables within the scope of the loop is not a problem. Instantiating class objects might be.

"Doesn't that imply all variables used in loop must be changed global since they get reset each time the loop is iterated? I am confused"

That is how C works. If you want them to maintain values everytime you call loop, use the static keyword which will only initialize them the first time through the loop.

KeithRB:
the static keyword which will only initialize them the first time through the loop.

It's only a small distinction, but I think the initialisation actually happens at cinit time when initialised global data is initialised, rather than at loop execution time. (I guess that distinction might matter in some corner cases where the initialisation expression depends on the state of other data.)

I am not sure about that, since initializations in functions can have non-constant initializers.

KeithRB:
I am not sure about that, since initializations in functions can have non-constant initializers.

The value when the static initialisation occurs is the result of evaluating the initialiser during cinit, not at the time the variable first comes into scope. (Hence my comment about corner cases.) There's a similar issue with class initialisation and global data initialisation which can produce some unexpected bugs if you try to use the Wiring API since this occurs before the Wiring init() has occurred.

You are correct, as you usually are.

According to Harbison and Steele (Which I should have checked) "If the variable is static or external, the expression must be a constant."

Hi, I am watching this thread with interest, and most are saying its data overload, well have you tried slowing down the baud rate just to see if the probem is arduino or lazy PC?
Try snail pace 9600baud.
Slow the process down so you can then do debug serial prints to see what "result" is actually equal too
and even perish the thought a delay(500), to see if you need more time.

Just a thought from the side lines.
Also have you tried a different monitor program?
Tom..... :slight_smile: