SpenceKonde / ATTinyCore

Arduino core for ATtiny 1634, 828, x313, x4, x41, x5, x61, x7 and x8
Other
1.6k stars 310 forks source link

2.0: panic: no major version found #703

Closed pepijndevos closed 2 years ago

pepijndevos commented 2 years ago

The mere presence of the library causes this error, even when compiling for a completely different board. This is on Arduino 1.8.19

Arduino: 1.8.19 (Linux), Board: "Arduino Uno"

/usr/share/arduino/arduino-builder -dump-prefs -logger=machine -hardware /usr/share/arduino/hardware -hardware /home/pepijn/.arduino15/packages -hardware /home/pepijn/Arduino/hardware -tools /usr/share/arduino/tools-builder -tools /home/pepijn/.arduino15/packages -libraries /home/pepijn/Arduino/libraries -fqbn=arduino:avr:uno -vid-pid=2341_0043 -ide-version=10819 -build-path /tmp/arduino_build_988146 -warnings=default -build-cache /tmp/arduino_cache_801952 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avr-gcc.path=/home/pepijn/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7 -prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino7.path=/home/pepijn/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7 -prefs=runtime.tools.avrdude.path=/home/pepijn/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17 -prefs=runtime.tools.avrdude-6.3.0-arduino17.path=/home/pepijn/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17 -prefs=runtime.tools.arduinoOTA.path=/home/pepijn/.arduino15/packages/arduino/tools/arduinoOTA/1.3.0 -prefs=runtime.tools.arduinoOTA-1.3.0.path=/home/pepijn/.arduino15/packages/arduino/tools/arduinoOTA/1.3.0 -verbose /home/pepijn/code/badge/uartproxy/uartproxy.ino
panic: no major version found

goroutine 1 [running]:
go.bug.st/relaxed-semver.MustParse(...)
    go.bug.st/relaxed-semver@v0.0.0-20190922224835-391e10178d18/parser.go:19
github.com/arduino/arduino-cli/arduino/cores/packagemanager.(*PackageManager).loadPlatforms(0xc00035a3c0, 0xc0001fc200, 0xc000742fd0)
    github.com/arduino/arduino-cli@v0.0.0-20210514123546-d710b642ef79/arduino/cores/packagemanager/loader.go:175 +0x123b
github.com/arduino/arduino-cli/arduino/cores/packagemanager.(*PackageManager).LoadHardwareFromDirectory(0xc00035a3c0, 0xc000354280)
    github.com/arduino/arduino-cli@v0.0.0-20210514123546-d710b642ef79/arduino/cores/packagemanager/loader.go:120 +0x6c8
github.com/arduino/arduino-cli/arduino/cores/packagemanager.(*PackageManager).LoadHardwareFromDirectories(0x2?, {0xc000161f40, 0x3, 0xc000354470?})
    github.com/arduino/arduino-cli@v0.0.0-20210514123546-d710b642ef79/arduino/cores/packagemanager/loader.go:45 +0x65
github.com/arduino/arduino-cli/legacy/builder.(*HardwareLoader).Run(0xc000101000?, 0xc000101000)
    github.com/arduino/arduino-cli@v0.0.0-20210514123546-d710b642ef79/legacy/builder/hardware_loader.go:29 +0x13f
github.com/arduino/arduino-cli/legacy/builder.(*ContainerSetupHardwareToolsLibsSketchAndProps).Run(0xc0002dbce0?, 0xc000101000)
    github.com/arduino/arduino-cli@v0.0.0-20210514123546-d710b642ef79/legacy/builder/container_setup.go:50 +0x2cb
github.com/arduino/arduino-cli/legacy/builder.runCommands(0xc000101000, {0xc000171d18, 0x2, 0x562ac2a7dd5d?})
    github.com/arduino/arduino-cli@v0.0.0-20210514123546-d710b642ef79/legacy/builder/builder.go:191 +0x1be
github.com/arduino/arduino-cli/legacy/builder.(*ParseHardwareAndDumpBuildProperties).Run(0xc0002dbf40?, 0x562ac2ef6418?)
    github.com/arduino/arduino-cli@v0.0.0-20210514123546-d710b642ef79/legacy/builder/builder.go:182 +0xac
github.com/arduino/arduino-cli/legacy/builder.RunParseHardwareAndDumpBuildProperties(...)
    github.com/arduino/arduino-cli@v0.0.0-20210514123546-d710b642ef79/legacy/builder/builder.go:214
main.main()
    github.com/arduino/arduino-builder/main.go:391 +0x1045
/usr/share/arduino/arduino-builder returned 2

Error compiling for board Arduino Uno.
SpenceKonde commented 2 years ago

That's an IDE bug, as far as I am aware, and I have not heard any explanation of how it is triggered, by my core or anything else. But it seems to impact only versions after 1.8.13. Thus 1.8.13 the only version of the IDE that's really usable (up until 1.8.12, they put inapplicable entries into tools-> programmers, assuming every programmer could support every part. Needless to say that is not the case, and because it used the platform.txt file that came with the programmer definition, every core had to supply their own copy of every common programmer. So you'd end up with a dozen programmers or so per core installed, ex, you'd see 4 "USBAsp" programmer options... but only one of them would use the correct platform.txt and work).

I don't know the language that's written in, or have any idea how to debug it, and I haven't been able to get anyone who does to help out, so all I can advise is going back to 1.8.13, which is what I use for everything. Because of this bug. I don't know what supposed improvements they've been working on in 1.8.x

Notice that when it manifests it fails on all boards, not just ATTinyCore. At least that's the behavior I see with it. I don't know what causes it o what it thinks should have a major version and doesn't. The core certainly does. It's a real mystery. Wouldn't it be nice if the error message the IDE printed told you what it was that it was crashing because it couldn't determine the major version of? Since it's such a serious error that it prevents all compilation? But they don't, the problem reproduces only erratically for me, and nobody has given an explanation of what is wrong or - if it is related to my core - how I could fix it.

SpenceKonde commented 2 years ago

Closing because we cannot fix this as it is a bug in arduino.

Only advise I can give until they finally decide to care about the huge regression they introduced in 1.8.14 is to stick with 1.8.13, which thankfully fixed the bug that displayed inappropriate programming tool options. At least we got one working versinon before they took a hammer to other key functionality.

I have not been able to find any information on how this could be fixed from the core, If anyone knows. please reopen this issue and tell me!

AndrioCelos commented 2 years ago

It seems to be choking on this line:

https://github.com/SpenceKonde/ATTinyCore/blob/e1cd63ded0e199b7a11f0de11ff5cbf62d34f69b/avr/platform.txt#L14

I got the Blink sketch to build by replacing it with the following:

version=2.0.0-dev
per1234 commented 2 years ago

Hi all. The bug in Arduino CLI that caused this panic has now been fixed: https://github.com/arduino/arduino-cli/pull/1830

I apologize for the inconvenience.

I have not heard any explanation of how it is triggered

I explained it to you on the forum here:

https://forum.arduino.cc/t/panic-no-major-version-found/876644

what it thinks should have a major version and doesn't

This line:

https://github.com/SpenceKonde/ATTinyCore/blob/e9cf2f34ed9e258e79598d280346296c920d92f8/avr/platform.txt#L14

The property references were not being expanded, so it was treated as that literal string, which of course is not a valid version.

the problem reproduces only erratically for me

In addition to the condition of using the affected versions of Arduino IDE (>1.8.13, <=2.0.0-rc9.1) or Arduino CLI, the other required condition is to have manually installed the boards platform in the sketchbook folder. The Boards Manager installations don't use the version property.

With those conditions satisfied, it should be consistently reproducible. I provided instructions for a minimal reproduction using Arduino CLI here:

https://github.com/arduino/arduino-cli/issues/1823

I have not been able to find any information on how this could be fixed from the core

As AndrioCelos explained already, the workaround is to refrain from using property references in the version field of platform.txt:

-version={versionnum.major}.{versionnum.minor}.{versionnum.patch}{versionnum.postfix}
+version=2.0.0-dev

I would be happy to submit a pull request for the change if you would like.

ObviousInRetrospect commented 2 years ago

Any idea whether this is likely to be back ported to 1.8.x? given that the last hourly build was "LAST UPDATE: 24 Apr 2022, 23:52:49 GMT" I am assuming it is unlikely.

The current advice to use 1.8.13 is unfortunate given the log4j issues there.

per1234 commented 2 years ago

I don't know about 1.8.x, but I can tell you that the fix for this issue, as well as the fix for the megaTinyCore issue you reported (https://github.com/SpenceKonde/megaTinyCore/issues/751), is in the Arduino IDE 2.0.0-rc9.2 release that was made just minutes ago:

https://github.com/arduino/arduino-ide/releases/tag/2.0.0-rc9.2

Please give it a try and let us know if you have any problems or suggestions for enhancements.

ObviousInRetrospect commented 2 years ago

Awesome! I verified RC9.2 fixes both issues. Thanks for fixing these and delighted to have an RC I can recommend.

Where would you suggest sending those problems and suggestions? off the top of my head:

  1. SerialUPDI's error output is sometimes truncated or non-existent on 2.0 whereas on 1.x I get a full stack trace reliably
  2. New dark red on black for errors is far less legible than the 1.8.x color scheme
  3. Would be nice if clicking on compiler errors jumped to the referenced line
  4. Currently board menu settings are sort of persisted between saves and loads but not terribly reliably and in a way that is not obvious. Given the IDEs insistence of storing a sketch in a folder with a matching name, it would be logical to write a text based config file (.txt, .ini, .json, .xml, .dont_really_care_pick1) to configure the sketch settings. This would also help with sharing and with examples when particular configuration is needed
  5. A way to do sketch-level global defines would be extremely useful. I am irritated every time I have to go hack a setting in a core (like a UART buffer size) both because it is global and because it gets clobbered on upgrades. This could be either an explicit mechanism to set global defines (PIO-like), the save/restore from the above item, or a project.h in the sketch directory that is either automatically included (via Arduino.h probably) or that cores can choose to #include if it exists.6.
  6. In RC5 there was a bug where sketch compile and programming output randomly went to the wrong window when multiple sketches were open. I'll keep an eye out for it, it might have been fixed.7.

Happy to stick more carefully written versions of these wherever you suggest.

per1234 commented 2 years ago

Where would you suggest sending those problems and suggestions?

Formal bug reports or feature requests should be submitted to the issue tracker of the appropriate repository:

Less structured feedback or general discussion should be done on the Arduino Forum:

error output is sometimes truncated or non-existent on 2.0

This is being tracked here: https://github.com/arduino/arduino-cli/issues/1818

New dark red on black for errors is far less legible than the 1.8.x color scheme

This is being tracked here: https://github.com/arduino/arduino-ide/issues/1087

clicking on compiler errors jumped to the referenced line

This is already in progress: https://github.com/arduino/arduino-ide/pull/1275

It is currently not working on Windows, and there are some other minor issues (see the comments in the PR), but it is quite usable for me on Linux. If you would like to try it out, test builds are available from the links under the "Artifacts" section of this page:

https://github.com/arduino/arduino-ide/actions/runs/2781486653#artifacts

(note that GitHub requires you to be signed in to your account in order to download workflow run artifacts)

a text based config file (.txt, .ini, .json, .xml, .dont_really_care_pick1) to configure the sketch settings.

The capability has been requested in several forms. I think the most comprehensive discussion happens to have occurred in this proposal for doing it via comments in sketches:

https://github.com/arduino/arduino-ide/issues/2438

Your metadata file approach (which is less hacky than putting the info in the sketch code) has also been proposed and receives some discussion there as well.

That is in the Arduino IDE 1.x issue tracker, but the foundation of such a feature must be done in Arduino CLI, which will make it available both for using Arduino CLI directly as well as for all the tools that use Arduino CLI under the hood (e.g., Arduino IDE, Arduino Web Editor).

A sketch.json metadata file already exists, and provides just this capability in Arduino Web Editor and Arduino CLI:

https://arduino.github.io/arduino-cli/latest/sketch-specification/#sketchjson

A "sketch project file" was also recently added:

https://arduino.github.io/arduino-cli/dev/sketch-specification/#sketch-project-file

Arduino IDE will use the sketch.json data if you don't have a board selected, but this is likely only a side effect of Arduino CLI's recognition of the file rather than any intentional design.

Related:

sketch-level global defines

Tracked here: https://github.com/arduino/arduino-cli/issues/159

Request for adding support for them in the sketch project file: https://github.com/arduino/tooling-rfcs/issues/9

There is a collection of links to related requests and discussions here: https://github.com/arduino/arduino-cli/issues/846 That issue also explains how it is already possible to define global macros via Arduino CLI flags, and how that capability might easily be made more universally accessible.

sketch compile and programming output randomly went to the wrong window when multiple sketches were open. I'll keep an eye out for it

I am not aware of any reports of this issue. If you are still able to reproduce it with the latest version, please do submit a report to the arduino/arduino-ide issue tracker.