It's not an out-of-memory error. Try increasing the stack size.

I reproduced the error. On 2 million iterations, the code works. On 4 million iterations it segfaults. I dunno. #ifndef NULL #define NULL 0 #endif #DEFINE DBLQUOTE ascii(34) dim shared as string*1 ASCII(255) for i as integer = 0 to 255 ASCII(i) = chr(i) next function unEscape( byval s as string ) as...

I love you guys. Nice work.

I'm going to attempt to build the string a zstring ptr in order to eliminate that as a possibility. If that solves the problem I will try to come up with some sort of test which reproduces the segfault and then others (who understand the compiler better) can determine if it's a bug or not. At this p...

The revised split with the local list is about 4x faster for me as well.

I've gone over the code a dozen times now. The offending function creates a 30meg string which it then returns. It does not always throw a segfault, but occasionally it does, only in the instance where the string is greater than 10 megs. Even if I track down the error I'm not sure there's anything I...

I can change it over to byref, but the pass is not where the bottle neck is. And I also mostly cut the code of this sub and run it within routines so there is no pass at all, and no need to call it. I've found byval generally faster for simple data types, and byref faster for complex UDTs.

Debuggers are for ^&~* jobs. (j/k)

I'm running through the code now. I'll report what I find. The mere fact that it logs different types of errors should be an indication as to how odd this issue is.

fxm's : 4.9 x 10^-3 Mine( spots index) : 9.7 x 10^-3 Original : 2.16 Yours : 6.0 x 10^-1 Likely redundant calls to isSplittingChar are slowing it down. And then it segfaults on the destructor.

It's a segfault, but I can't figure out how it's being triggered. It would take a lot of effort on someone else's end to replicate the conditions, but it happens on different machines, with different data being passed to the same function. I'm batch processing some files, basically, and it calls to ...

The most recent copy of my json parser is contained in the first post. There have been some updates, bug fixes, and assorted goodies.

Error in `./stat_builder': corrupted double-linked list: 0xbf849a50

I already increased stack space, so I'll just stick it on the heap. Thanks guys. I do compile linux versions so I'll take a look to see if there is an issue increasing the stack on linux systems.

There does not appear to be a significant increase. I ran timer test about a dozen times and the results were inconsistent but average out to about even.

I'm getting a 33% increase in speed from my second attempt. Excellent. Thank you fxm.