RangeError: invalid string length about linter-gcc HOT 26 CLOSED

Could you open the developer console with Ctrl+Shift+I, copy the linter-gcc command, paste it into a terminal, run it, and post the output here?

from linter-gcc.

Command output as requested:

21:10:23 ~ >/usr/bin/g++ -c -Wall -std=c++11 -fmax-errors=0 /Users/vision/git/sim/lib/rocket.hpp
clang: warning: argument unused during compilation: '-fmax-errors=0'

The error has also become intermittent, but I can change the file by just adding or removing an empty line and resaving and it may or may not happen again.

from linter-gcc.

Restarting Atom also makes the error go away for a while, but it comes back after working for some period of time.

from linter-gcc.

I am concerned that your code is generating an error message that is just too long for linter to handle, a template error perhaps? Are you happy to post a sample of your C++ code so I can test it?

from linter-gcc.

Same bug here, quite often :/

I got it with C code, not C++. And gcc isn't showing any error while compiling the file with the same command-line than linter-gcc.

from linter-gcc.

Ok. Let me try to reproduce the error and I will post a fix asap.

from linter-gcc.

Could someone give me a code sample that's causing the error?

from linter-gcc.

When i have the error, reopening atom is usually enough to not having it again. So giving you a code that's causing the error will not be helpfull, as it will not cause the error on your side.

from linter-gcc.

This is very strange. I thought it was related to the error messages being very long, but it looks like that's not the case. I've deliberately linted source files that generate long error messages and everything works fine.

from linter-gcc.

Having some news : when the "invalid string length" bug occurs, the errors pops every time i'm saving a file even if it's not the file that caused the error, and even if the file doesn't have any error.

from linter-gcc.

I'm having the same issue, any update on this? It only started to occur after I upgraded atom to 1.5.3. I've also kept up to date on linter-gcc, and it started breaking just today, so it must have been in a recent update that it started happening.

from linter-gcc.

I have the same problem. After few hours of code writing i got long error. New errors come when i press Command-S to save(and lint) project. After I relaunch Atom, no errors, but after some time I have same errors. I have no errors if I disable or remove linter-gcc.

My project:
https://github.com/XSmile2008/BigTrackArduino

from linter-gcc.

I got the error 4 times in a hour now, it's very frustrating :s

Is there a solution yet ?

from linter-gcc.

Hello all. I think I have identified the problem. Need to play some more to make sure it's fixed. The issue seems to be that atom reports the settings tab as an 'editor' as well. I need to make sure that linter-gcc doesn't try to lint it when that happens.

from linter-gcc.

Ok it seems the editor problem is secondary. The main issue is that linter stringifies its messages using JSON.stringify in the latest release here. This problem is not present in the latest commit, however, so all we need is for the latest commit to be published as a release.

@steelbrain could you help us here? Are you planning on publishing a new release soon?

from linter-gcc.

I am planning on publishing a new release soon but the workaround should work well for you, the only penalty should be performance and even that won't be anything major, worst case scenario you miss a frame which isn't too bad for a workaround IMHO

from linter-gcc.

Sounds good. Workaround details:

• Open Atom's package manager, find the linter package
• Click Settings, then View Code
• Open the file lib/validate.coffee
• Goto line 53:

result.key = JSON.stringify(result)

• Add the following line immediately before it:

result.key = null

• Save the file, and restart Atom.

Let me know if the workaround fixes the problem. Once the new version of linter is released, this issue will be fixed.

Edit: Please ignore this workaround. The issue will be fixed in the next release of linter-gcc

from linter-gcc.

This is not really the workaround, the workaround I suggested should be done by the providers and not the end users themselves, I suggested JSON.parse(JSON.stringify(messages))

Another approach to solve this would be to solve only the text instead of message objects and then do

const messages = []
for (const message of this.errors) {
  messages.push({type: 'Error', text: message.text, range: message.range})
}

from linter-gcc.

@steelbrain but the issue is that the base linter does the stringification, not linter-gcc. linter-gcc simply passes the messages to linter. Any ideas as to how to work around this problem?

from linter-gcc.

Change this line to module.exports.linter_gcc.setMessages(JSON.parse(JSON.stringify(require("./utility").flattenHash(module.exports.messages))));

from linter-gcc.

@steelbrain thanks for the help. The workaround has been implemented. Please update linter-gcc.

from linter-gcc.

A friend of mine just got the error again :s He's on 0.6.8 update !

from linter-gcc.

Has he restarted Atom? A restart is necessary to reload the package.

from linter-gcc.

I have run tests with the BigTrackArduino project, and the issue before was that one of the message objects passed to linter would grow in size if you opened more than one file. This could continue until the object was too big for node to handle. Now, the size of all objects remains the same no matter how many files you open/save.

from linter-gcc.

Ah maybe not, he can't remember ! Indeed, i don't have the error now ^^

Thanks for the patch !

from linter-gcc.

No problem. Glad it's all working again. I will update linter-gcc again once linter has been updated.

from linter-gcc.