gc:arc - Illegal storage access #15954
Comments
Valid bug of course but you should really use |
|
Thank's for the adivce - but any idea what the valid bug could be related to? |
|
To this very statement ( |
|
@SFR0815 there are many things you can do to improve your bug report:
without any minimum reproducible example, not much one can do about it |
|
I will go item by item. Order will be somewhat different: No. 2: show full stacktrace |
|
No. 3: does it happen without --gc:arc No. Without --gc:arc everything is fine. |
|
from the stacktrace + code in alloc.nim please also re-run your code with |
|
nim c -r --gc:arc -d:useSysAssert ut_uiapi_list.nim gives: [SYSASSERT] rawAlloc: requested size too small |
|
even with please put yourself in position of someone looking at your bug report; it's really hard to do anything about it without any context or minimized reproducible example. what is the code of getDateOfDateString? or ideally, what's the content of iso8601.nim (eg put in some gist https://gist.github.com/) |
|
I fully understand that without a code example it's a mess. No clue on how I can help on this. Please note the following: No. 1: add echo type(result) and report it Just in case it is of help here comes the code of my proc that produces the issue: Line 261 is " day = day & $character" I just introduce " echo "typedesc of day: " & $typedesc(day)" before line 261 ... here comes the funny peace: Will try my luck on the gist |
|
|
|
No. 4: check whether same root cause as #13137 |
|
No. 5: if result is cstring, |
|
No. 6: echo castint => this will help determine if address is from ROM or heap or stack Code is now: results in: (was able to reproduce as mentioned above ...) This just goes before the line causing the issue and provides: |
|
Comment: |
|
No. 7: also run on devel Well, I was on devel (see above). Just updated to: running |
|
@SFR0815 can you try to re-run with this modified code and show the relevant output? if echo makes the bug go away there's other options ( proc getTimestamp*(date_time: times.DateTime): string =
echo date_time
let full_date_time_format_string = getStandardDateTimeFormat_String() & "zzz"
echo full_date_time_format_string
let full_date_time_format = full_date_time_format_string.initTimeFormat()
echo full_date_time_format
result = date_time.format(full_date_time_format)
echo result
if result.endsWith('Z'):
echo "ended_with_Z"
result.removeSuffix('Z')
echo result
echo "before_crash"
result = result & "+00:00"
echo "after_crash" |
|
OK - will amending code accordingly on both occasions gives: |
|
thanks; from what I gathered it looks unlikely the bug is in I was hoping if the code is not confidential, you could create a test branch + a cmdline to reproduce the bug; the more minimized it is the better for whoever looks at it if it's a nim bug, it should be investigated and resolved though. What I usually do here when all else fails is painfully minimize: create a test git branch in your code (to avoid messing with your normal branch in your code), then keep simplifying the code while retaining the bug; this is not a fun thing to do but it works. hopefully one day nim catches up to D's dustmite (see https://github.com/CyberShadow/DustMite/wiki and #8276) and then this would all become automatable (dustmite is a joy to use in my experience) |
|
No. 8: with above info in mind, minimize & reproducable error etc. Code is not confidential. Happy to share in whatever state. A big sorry for party messy WIP upfront. We do not keep it on GitHub but on our own server, though. The issue occurs on an exercise that
As I mentioned, --gc:arc worked smoothly on tons of tests on #1 & #2. I would have been very surprised to see iso8601 being the cause of the issue. Thus, from my side, the outcome of today's matches expectations. Serves as a starting point. In order to get closer to the issue, I would like to propose the following: Cheers and thank you for your help |
|
One last item re the above: To be blunt, I am not actually from a planet in the vicinity of Betelgeuse, and, thus, my expertise on gc related issues is limited. If I understand your comment "gc corruption likely ocured in some earlier place in your program" as: There is some pointer associated to some ref object (addr) getting corrupted on the way and thus causes Is that correct? ... It might be helpful to ensure a proper understanding of what I am searching for. |
yes. That type of bug is harder to track down because the bug can occur earlier but the stacktrace only shows a symptom
result = result & "+00:00"
=>
result.add "+00:00" # not just workaround but actually better (but original bug still is a bug!)
# or even, avoiding touching `result` at all:
var ret: string
ret.add result
ret.add "+00:00"
return ret |
|
OK that serves as a starting point. Thus, will round up the usual suspects first. |
|
Does your program run on Linux or OSX? If so, compile with |
|
Unfortunately, it's Windows. |
|
Some update on the above: I have made some changes on the famous iso8601 - a couple of improvements like using 'add' as suggested above. This actually made the FIRST test of my test suite pass with success. The SECOND test still ends with error (currently at some renderSQL command) - only difference to test no.1 is parameters Errors raised are mainly related to string/char operations. "thing" parameter on add in parsesql is a "=" |
good, but the underlying problem might still be there, correct? my understanding is that #16365 is a separate issue from this one; if so both need to be minimized (yes, it can take some work sometimes, but it always pays off) |
Hi!
First of all I have to apologize that I can not actually provide a simple code example causing the issue - the code I am running is a bit too large to be documented here. I have not yet been able to identify where this below mentioned behavior actually originates form.
What I observe is that "nim c -r some_file.nim" does not cause any issue
while "nim c -r --gc:arc some_file.nim" fails with
..\nim-1.4.0\lib\system\alloc.nim(955) alloc ..\nim-1.4.0\lib\system\alloc.nim(787) rawAlloc SIGSEGV: Illegal storage access. (Attempt to read from nil?)
with line of my code mentioned to fail just does some trivial stuff (like: result = result & "x")
The text was updated successfully, but these errors were encountered: