Good Morning All,

I hope everyone had a good Thanksgiving!

I am trying to import a CSV file into a preloaded xtree. The upload process seems to go smooth but when I display the xtree again I will get a Segmentation Fault. Small CSV files work just fine (<500), but large CSV files are where I start seeing this issue (>2000). I feel like I may be running into a memory issue of some sort. Any other ideas on what could be going on? Possible solutions?

Version 7.0.1765.1

Thanks
Kyle Vaughn

Yes we're all tanked up on turkey and ready for the year-end crush!

I'm not quite sure what is happening here, but I kind of doubt that it's simply a matter of overall size of the CSV. Unfortunately XTREE offers a nearly infinite number of permutations of the various options and attributes, so it's likely specific to the particular combination you're using, perhaps in conjunction with some specific data pattern. You didn't indicate what kind of units you were referring to (lines, columns, KB, etc.) but I just tried the XTRCSV.BP sample program from the EXLIB, with various CSV files, including a rather large USZIPS.CSV (available for download here via USZIPCODES.ZIP which contains 42K lines, each with 13 fields, 4.5MB in total size.

Other than entering the name of the CSV, I just selected all the defaults in the sample program, and then tried the options to re-enter using XTROP_REPLACE or XTROP_RESELECT. It's a bit slow (taking several seconds for the tree to fully-load and become responsive), but I didn't run into any crash issue.

I suggest first checking the ashlog.log to make sure there aren't any good clues there (like a telltale message before the crash). Also, activating the XTREE and XDEBUG traces in the system message window sometimes helps reveal useful details (including the actual coldef specification). Then I suggest downloading the sample program and trying it with the USZIPS.CSV file as well as with your file. If neither crashes, then I would suggest comparing the options in the two programs to see if you can modify XTRCSV to be like yours and crash. If no luck there, feel free to post or email me your program and data so I can try to reproduce it here.

Hey Jack,

I'm about to try the XTREE/XDEBUG traces, however, I wanted to add some information before I forgot.

The issue isn't the size of the CSV file, just the number of rows added after the initial load. For example, if I have 500 items loaded and then import 500, things seems to work. If I have 500 loaded, then import another 2000, that's where I start to see the issue. I have been able to navigate the error by clearing the xtree, reloading the original data, importing the data, and finally doing the display.

Thanks,
Kyle Vaughn

It sounds like you must be using the XTROP_APPEND opcode? I suspect that it isn't used much, other than for appending a small number of lines (typically one) at a time, as in the shopping cart example XTRA4.BP. So it's not hard to believe that what you're describing hasn't been tested much. I'll see if I can work up a test on my end as well.

Hi Jack,

I can provide more context as this is using our dialog generator. The generated XTREE code uses XTROP_REPLACE the _display() procedure. This technique has not been a problem for us and makes coding easier not dealing with the opcode in application code. We are using XTF2_ANSEQDATA as well.

I tried various combinations in CSV mode, using XTROP_REPLACE and/or XTROP_APPEND to add hundreds or thousands of lines, but haven't been able to reproduce the issue.

But your comment about XTF2_ANSEQDATA seems to suggest regular array mode (as opposed to CSV mode), so I'm still a bit unclear as to the details.