Teensyduino compiler crash !

Status
Not open for further replies.
H

HachavBanav

Member
I am suffering from a java crash when compiling the attached sketch (for Teensy 3.0 using 2 serial modules : Bluetooth HC-05 + SigFox TD1208)

I although attached the buildprefs.txt, stderr.txt (full error text), stdout.txt contains 30 Cr&Lf.

I am using Teensyduino 1.25 on Arduino 1.6.5.
I have other sketch that successfully compiled and ran well.

Any help appreciated !
I promissed I'll publish the code ... if it works :rolleyes:
 

Attachments

  • Bilote.ino
    9.6 KB · Views: 113
  • stderr.txt
    190.2 KB · Views: 127
  • buildprefs.txt
    1.7 KB · Views: 124
Do you have External Editor enabled in File > Preferences? A bug was introduced in Arduino that causes problems in that mode. The only workaround (so far) for external editor is downgrading to 1.6.3.
 
My "External editor" is not checked...

According to ProcessExplorer, the Teensyduino process is launched as below
"C:\Users\bruno.rivier\Documents\Soft\TeenSy\Arduino-1.6.5\java\bin\javaw.exe" -splash:./lib/splash.png -Dsun.java2d.d3d=false -Xms128M -Xmx512M -classpath "lib;lib\antlr.jar;lib\apple.jar;lib\arduino-core.jar;lib\bcpg-jdk15on-152.jar;lib\bcprov-jdk15on-152.jar;lib\commons-codec-1.7.jar;lib\commons-compress-1.8.jar;lib\commons-exec-1.1.jar;lib\commons-httpclient-3.1.jar;lib\commons-lang3-3.3.2.jar;lib\commons-logging-1.0.4.jar;lib\ecj.jar;lib\guava-18.0.jar;lib\jackson-annotations-2.2.3.jar;lib\jackson-core-2.2.3.jar;lib\jackson-databind-2.2.3.jar;lib\jackson-module-mrbean-2.2.3.jar;lib\java-semver-0.8.0.jar;lib\jmdns-3.4.1.jar;lib\jsch-0.1.50.jar;lib\jssc-2.8.0.jar;lib\pde.jar;lib\rsyntaxtextarea-2.5.6.1+arduino.jar" processing.app.Base "C:\Users\bruno.rivier\Documents\Soft\TeenSy\Arduino-1.6.5\Bilote\Bilote.ino"
 

Attachments

  • preferences.txt
    4.1 KB · Views: 145
Last edited:
Looks like you're missing a quote mark on line 73.

Code: 
            Serial.println("curinq);

Arduino's ad-hoc regex parsing strikes again! They're fixing this in Arduino 1.6.6, but when they release it is anyone's guess...
 
PaulStoffregen said:
Looks like you're missing a quote mark on line 73.

Code: 
            Serial.println("curinq);

Arduino's ad-hoc regex parsing strikes again! They're fixing this in Arduino 1.6.6, but when they release it is anyone's guess...
Click to expand...

Why does Arduino's IDE and build strategy (exclusive of the C/C++ pre-processor and compiler?) have to parse user code's strings (and crash due to a user's typo?)
 
stevech said:
Why does Arduino's IDE and build strategy ... have to parse user code's strings
Click to expand...

1: Automatic addition of function prototypes and
2: Detection of intended libraries for the build process.

(and crash due to a user's typo?)
Click to expand...

Because C/C++ is more complex that simple regex patterns can reliably parse.

They're (finally) changing to ctags and gcc preprocessing for 1.6.6, as well as a native build system (no Java).
 
Thanks.

I wonder if the automatic function prototyping and no pre-compiled binaries (.o, .a) is truly a simplification. Pro's and Con's.

The future for JIT or bytecode interpreters (Python, Javascript, Lua) with no need to declare variables and their type, may be that to which many/most avocational users will increasingly gravitate.
Having done three large projects (professionally) with Python, fiddled with Javascript on a low cost Cortex M3/M4, and messed with Lua a bit, I can see this from that avocational user's viewpoint.
For sure, these languages rely on C/C++ underpinnings for their speed and I/O intimacy. But of course, that's all transparent to said user.
These languages do truly give one a huge increase in functionality per hour of coding (or per line of code), versus that type of user struggling with C or worse, C++.

Then there's the issue of how many of those kinds of users will choose a $15-$25 M3/M4 type board with a high level language, versus $35 Linux board like RPi where all the languages are there, and most but not all of the I/O intimacy is present.

We'll see how this evolves. Sorry for rambling.
 
Would believe hundreds of other people have typed a similar message, questioning Arduino's fundamental design and viability of its future, pretty much every time these ugly regex limitations strike. Even though this is a fairly minor bug, it's somehow special in the conversation it always elicits. Talking about general market & tech trends (and predicting the decline/demise of very popular software) is a lot easier than diving into the thorny details of language parsing bugs and the many subtle issues with Arduino's somewhat unconventional self-configuring build.

Fortunately, the Arduino devs have been (finally) working on these long-standing issues. I've been somewhat involved in the process. Version 1.6.6 will be the first with a massively redesigned build system. Like any large software change, serious bugs will probably be discovered quickly as many people use it. I don't expect 1.6.6 to be perfect. In fact, I believe it'll be quickly replaced, like 1.6.0 and 1.6.2. But long-term, perhaps by 1.6.7 or 1.6.8, Arduino is moving to a far better build system that will make these regex issues a problem of the distant past.

Perhaps scripting languages will gradually replace Arduino & C++. I really don't know. Next year, when we have a more powerful Teensy, I'm planning to look more seriously at those systems. My goal is to help people make awesome projects, not to specifically champion one particular language. Arduino simply happens to be the most popular, best understood system available today. I can and will adapt as technologies change and improve (eg, USB didn't exist when I started). I may be an old dog by Silicon Valley standards, but I'm very capable of learning new tricks!

But I am a little cynical when I see the demise of Arduino predicted in response to this one particular regex bug. Arduino's had this bug for 10 years. It consistently prompts this exact conversation. The details of conjecture on what might replace Arduino change, but the regex error to premature predictions of Arduino's unsuitability as a long term viable platform never seem to change. Thankfully, this regex bug will be gone soon.
 
Although I have to use some of these these at my day job, I'm not at all a friend of high level languages. When I started writing software in the early eighties, every single byte was precious and nobody ever thought that runtime interpreters could one day replace clean, optimized, near assembler code.
It was what I call the "hardware inflation", quicker CPUs, cheaper RAM and mass storage, which taught us bad manners and waisting immense system resources: On a modern PC, more than 1GB of RAM is only needed to start the OS, even without an application running, just because the developers are aiming for quick (and often dirty) results instead of optimized binary code which makes a really meaningful use of the resources.

Developing for the Teensy in C/C++ including some asm() from time to time, never including any library before having analyzed, understood, and perhaps optimized its code for my specific purpose as a hobby brings me back to these good old times where programming was still a true science...
 
Many were increasingly of the opinion that they'd all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans.
Click to expand...

Having well supported tools to control the hardware/environment at hand it what matters most. Man got to the Moon with?

My first computer had BASIC - I missed the switches generation - got my CS degree on lots of commercially acceptable languages and not C that I picked up on my own. My first job was on a PC with interpreted BASIC - Providing machine status and feedback and keeping records for the FDA as the machines were making Penicillin. Later jobs evolved to C and Windows as BASIC stayed static. My first bad job review was 'poor commenting' - the comments had to come out as they ate my 64KB code space 'byte for byte' and the job wasn't done.

For the problem at hand and making good use of the hardware - Arduino and it's C/C++ is a good fit. Doesn't have the processing power of a smart/telephone these days, but is a great learning (and doing) tool. Indeed Theremingnieur - hardware inflation is like abuse of storage for install media - 1 floppy to multiple to 1 CD to multiple to 1 DVD to multiple. Luckily Moore was about right and hardware is doubling in power as often as it does - as the tools always expand to (ab)use the power at hand.

If you need a compiler to understand your typo's (yeah okay I do need to know what line) then that is like needing a spell checker to send a simple email because you never learned to spell, or type on your own papers on a impact ribbon typewriter. Now a texting master uses TLA's and Emoji's for the reader to decode, and couldn't form a meaningful paragraph. [ as a loose analogy to JIT and Bytecode and interpreting - the work has to get done somewhere and it is now being pushed back to execution time. A key feature of most every milestone of Android is 'faster' and yet it always seems sluggish. ]
 
I would have seen a "Java crash at compilation time due to a 10 years Arduino bug" sticky post in the Technical support forum...and fixed my typo silently
 
Status
Not open for further replies.
Back
Top