Memory leak in SRP List GetAt ?

MattCrozier

I've just been doing some benchmarking to see whether it's faster to use SRP_List_GetAt(), or OI's BRemove statement, to sequentially parse a list. I used this code:


declare function timegettime, srp_list_create, srp_list_getat
tot = 9999999

* Construct a sequential list
call rti_stringbuilder( h, 'New', tot*10)
for i = 1 to tot
call rti_stringbuilder( h, 'Append', i: @fm)
next i
call rti_stringbuilder( h, 'ToString', list, 1)
call rti_stringbuilder( h, 'Destroy')

* Access the list sequentially
Call Send_dyn( "Start Test")
startTime = timegettime()
p=1
h = srp_list_create( list, @fm)
for i = 1 to tot
k = srp_list_getat( h, i)
*Bremove k from list at p setting d
next i
call srp_list_release( h)
retVal = timegettime() - startTime
Call Send_dyn( retVal)
Return retVal
OpenInsight crashed during the process using SRP_List_GetAt(). I could see in Task Manager that memory usage on the OINSIGHT.EXE process just kept increasing during the test loop before that happened. This is using SRPutilities v1.4.8 on OI 9.4. BTW, BRemove is lightning fast!, at least compared to constructing the list initially. Cheers, M@

KevinFournier

BRemove will always be fastest for sequential reading. I double checked SRP_List_GetAt and confirmed that there are no memory leaks in the strictest sense (i.e., all pointers are getting garbage collected upon release.) However, I am sure that behind the scenes Microsoft optimizes memory usage by keeping it allocated (even when no longer needed) because it knows there's plenty of memory to go around these days. Based on your post, it does not seem to be causing problems. It's not crashing or hanging, correct?

MattCrozier

Hi Kevin,

Yes, it is crashing with "OpenInsight has stopped working". Actually - it seems to happen in SRP_List_Create()! It doesn't even get to the loop.

From the Event Viewer:

Faulting application name: OINSIGHT.exe, version: 9.4.0.0, time stamp: 0x51ad1331
Faulting module name: SRPUTILITIES.dll, version: 1.4.8.0, time stamp: 0x546157de
Exception code: 0xc0000094
Fault offset: 0x0002b8d6
Faulting process ID: 0xce0
Faulting application start time: 0x01d0198fa9c4d1be
Faulting application path: C:\TEMP\WC8.0.dev\OINSIGHT.exe
Faulting module path: C:\TEMP\WC8.0.dev\SRPUTILITIES.dll
Report ID: 66933233-8583-11e4-82a3-74d4358f5f64
Faulting package full name:
Faulting package-relative application ID:

HTH, M@

KevinFournier

Okay, I was able to recreate this. It wasn't a memory leak issue, it was a bug that occurs when the OI array used to initialize the SRP list is very large. This will be fixed in the next release.

Also, since this was brought about by benchmarking, I want to mention another reason why BRemove is so much faster the SRP List for sequential reading. SRP Lists are indexed so that Locates are blazing fast. Indexing takes time, however. So, the rule of thumb is: if you are going to access elements in sequential order, use BASIC+, but if you are going to access elements in no particular order, use SRP Lists.

MattCrozier

Great stuff - thanks Kevin. That's useful to know.

Cheers, M@