You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a bug that sometimes occurs in my real code. I have been able to produce a reproducible test case that always seg faults for me, which I am attaching here.
The culprit function is CoalesceAndPreparePlotOptionsArray. The function has some parts that don't seem to be directly related to the crash, but if I remove some of them, then I sometimes don't get the crash.
For some context of what this function was trying to do: it was trying separate out some x/y values to be plotted on a chart. But the input arrays may have multiple entries for the same value of an x, which the charting library may not like. So the top half of the function is iterating through the source array looking for adjacent duplicates (the array is assumed to be ordered), and then coalescing the results into a temporary array called coalesce_transaction_history.
In this reproducible test case, there are no duplicate x entries, so the else path is always run, and coalesce_transaction_history becomes an array that shares all the same records as the original source array.
Then the start of the next half of the function is where the crash happens. The next half of the function is supposed to iterate through the entire coalesce_transaction_history array and then create a different type of object that contains just the data that would be needed for plotting and putting that into tgt_array.
But for me, I get a segmentation fault on the 2nd (or maybe it is the 3rd object...I print a bunch of debug messages and I see i:2 as the last thing before the crash.). Checking the size of the array looks correct, but it seems like the element is either gone or the wrong area of memory is being accessed.
Additionally, if I run in pure Lua mode (--emit-lua), I never get a crash and my program produces my expected results. So this means only the Pallene/C code generation has the bug.
I started thinking it could be a reference holding/garbage collection bug since it felt like the elements were disappearing, but I actually can't distinguish it from a simple memory corruption bug. So don't let the verbage/comments of some of the things in my code throw you off.
I place these files in pallene/experiments/stocks3 gcbug.tar.gz
The text was updated successfully, but these errors were encountered:
I forgot to mention that there is a comment in the code where if I deep copy the object and put it into the coalesce_transaction_history array, it seems to workaround the bug. In this supplied test case, that workaround does not seem to work here.
Maybe this is the same bug as #485... Thanks for the new test case though; these bugs are tricky to debug so more test cases always help.
I started thinking it could be a reference holding/garbage collection bug since it felt like the elements were disappearing, but I actually can't distinguish it from a simple memory corruption bug.
Could you please try adding a call to collectgarbage("stop") in the GCRunBug.lua? Does the crash still happen if we disable the garbage collection?
I have a bug that sometimes occurs in my real code. I have been able to produce a reproducible test case that always seg faults for me, which I am attaching here.
The culprit function is
CoalesceAndPreparePlotOptionsArray
. The function has some parts that don't seem to be directly related to the crash, but if I remove some of them, then I sometimes don't get the crash.For some context of what this function was trying to do: it was trying separate out some x/y values to be plotted on a chart. But the input arrays may have multiple entries for the same value of an x, which the charting library may not like. So the top half of the function is iterating through the source array looking for adjacent duplicates (the array is assumed to be ordered), and then coalescing the results into a temporary array called
coalesce_transaction_history
.In this reproducible test case, there are no duplicate x entries, so the
else
path is always run, andcoalesce_transaction_history
becomes an array that shares all the same records as the original source array.Then the start of the next half of the function is where the crash happens. The next half of the function is supposed to iterate through the entire
coalesce_transaction_history
array and then create a different type of object that contains just the data that would be needed for plotting and putting that intotgt_array
.But for me, I get a segmentation fault on the 2nd (or maybe it is the 3rd object...I print a bunch of debug messages and I see i:2 as the last thing before the crash.). Checking the size of the array looks correct, but it seems like the element is either gone or the wrong area of memory is being accessed.
Additionally, if I run in pure Lua mode (--emit-lua), I never get a crash and my program produces my expected results. So this means only the Pallene/C code generation has the bug.
I started thinking it could be a reference holding/garbage collection bug since it felt like the elements were disappearing, but I actually can't distinguish it from a simple memory corruption bug. So don't let the verbage/comments of some of the things in my code throw you off.
I place these files in pallene/experiments/stocks3
gcbug.tar.gz
The text was updated successfully, but these errors were encountered: