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 small sample program attached which triggers a Segmentation fault for me.
I'm not exactly sure of the reason, but one of my suspicions is it may be related to me passing a Lua function into Pallene.
Because require and the io library is not available directly inside Pallene, I did what I saw recommended in the Issues/Discussions, and passed Lua functions and objects through a function call into Pallene so I could invoke them there.
Specifically, I am passing a FILE (from io.open), the function filehandle.lines, and another Lua function to help parse stuff.
My program is simply trying to read from file SPY.csv, which is daily historical stock data from the S&P 500.
I am trying to store all the data into an array of Pallene records.
The program:
reads the file line by line in Pallene LoadHistoricalDataFile
for each line, parses up the string calling Lua LuaParseStockCVSLine
Takes all the primitive values returned from the parser, and creates a StockRecord
Appends the StockRecord to an array of StockRecords
When I run the program, it crashes after a number of iterations in the loop.
I originally thought maybe there was some kind of bug that was not resizing the array under the hood, because originally my program crashed on the 17th element. But changing the program around, I find it crashes in different places. I've gotten it to crash 200+ elements in, and the program I'm submitting crashes on the 12th element.
The reason I thought maybe this could be related to passing Lua functions to Pallene, is because I originally was going to submit a more minimal example that didn't read from a file. But when I removed the code that was passing the lines() function, the code stopped crashing.
I then started wondering if the problem is related to the type signature I provided for lines(). I am not sure if my signature is actually correct. However, when I put really wrong things in, the compilers or runtime would complain. So what I have in the code works just enough to yield correct looking results.
And I'm not sure if that function can return a different number of arguments for different situations, and I don't know what to do for those kinds of situations. But for my case, all the lines being parsed should trigger the same code paths in lines() so the number of arguments should always be the same since the program crashes before I get to the end of the file.
But this could be a red herring. I also discovered that deleting some unused code, would allow the program to finish without crashing, or get farther through the loop before crashing. For example, in the main.lua, if I deleted or commented out the function PrintDebugLuaStockArray (which is never called), the program seemed to make it through to the end without crashing.
And in stocks.pln, if I deleted all the code related to the integer i counter (which only exists to help me print/debug), the program would make it through more iterations of the loop before crashing.
Anyway, regardless, my impression is that Pallene is supposed to be "safe" for anything I write at this level, so seg fault seems like a bug that you probably would like to investigate.
PalleneStocksArrayCrash.tar.gz
Extract this in the root directory of your pallene repo, and it will create: examples/StocksArray/
You can build and run it individually like the other examples.
The text was updated successfully, but these errors were encountered:
I have a small sample program attached which triggers a Segmentation fault for me.
I'm not exactly sure of the reason, but one of my suspicions is it may be related to me passing a Lua function into Pallene.
Because require and the io library is not available directly inside Pallene, I did what I saw recommended in the Issues/Discussions, and passed Lua functions and objects through a function call into Pallene so I could invoke them there.
Specifically, I am passing a FILE (from io.open), the function filehandle.lines, and another Lua function to help parse stuff.
My program is simply trying to read from file SPY.csv, which is daily historical stock data from the S&P 500.
I am trying to store all the data into an array of Pallene records.
The program:
When I run the program, it crashes after a number of iterations in the loop.
I originally thought maybe there was some kind of bug that was not resizing the array under the hood, because originally my program crashed on the 17th element. But changing the program around, I find it crashes in different places. I've gotten it to crash 200+ elements in, and the program I'm submitting crashes on the 12th element.
The reason I thought maybe this could be related to passing Lua functions to Pallene, is because I originally was going to submit a more minimal example that didn't read from a file. But when I removed the code that was passing the lines() function, the code stopped crashing.
I then started wondering if the problem is related to the type signature I provided for lines(). I am not sure if my signature is actually correct. However, when I put really wrong things in, the compilers or runtime would complain. So what I have in the code works just enough to yield correct looking results.
And I'm not sure if that function can return a different number of arguments for different situations, and I don't know what to do for those kinds of situations. But for my case, all the lines being parsed should trigger the same code paths in lines() so the number of arguments should always be the same since the program crashes before I get to the end of the file.
But this could be a red herring. I also discovered that deleting some unused code, would allow the program to finish without crashing, or get farther through the loop before crashing. For example, in the main.lua, if I deleted or commented out the function PrintDebugLuaStockArray (which is never called), the program seemed to make it through to the end without crashing.
And in stocks.pln, if I deleted all the code related to the integer i counter (which only exists to help me print/debug), the program would make it through more iterations of the loop before crashing.
Anyway, regardless, my impression is that Pallene is supposed to be "safe" for anything I write at this level, so seg fault seems like a bug that you probably would like to investigate.
PalleneStocksArrayCrash.tar.gz
Extract this in the root directory of your pallene repo, and it will create: examples/StocksArray/
You can build and run it individually like the other examples.
The text was updated successfully, but these errors were encountered: