In the same vein as Trapping "the index was outside the bounds of the array" error - #11 by also, I have a crash I’ve been trying to solve.
In C10.12567, I sometimes get an exception window like this, despite using the supplied “debug” ClaRun.dll.
If you have any suggestions about how I could further investigate what’s happening, I would appreciate it very much.
The 9242 seems to be a common part of the reported address, but the address sometimes has a different value at the beginning. eg. xxxx9242. At other times, it will be xxxxBEAD
I suspect it’s a non-threadsafe operation on a static entity, but not sure what thing is doing it.
Looks like result of the
instruction was executed with negative value for the move counter (register ECX). Moving executed until destination address not reached the end of committed memory block. LOG file is required.
Sounds, the exception occurs on compressing a queue record. The QUEUE stuff compresses records with large size on ADD and PUT and decompresses them on GET.
The Base pointer looks compromised EBP=000000A1 , Stack pointer is quite strange comparing to values I usually see near 0019… and your shows ESP=2E48FBB4, look at the values showed on the thread you linked
Perhaps the execution jumped to and invalid address (this don’t say why or from where)
It’s OK. The compression and decompression functions are written on assembler and they use the EBP register as a general purpose register.
Thanks, I overlooked it and the other registers and parameters too.
A pity using EBP in that way prevents gathering the call stack.
It would be useful to see the nearby instructions (Clarun+19242) at Jeff’s specific version used.
Browses’ Queues has the ViewPosition STRING(1024) , they would be considered large for compressing them?
The focus was on efficiency. The compression/decompression code was not changed since 1998 year.
QUEUEs’ stuff tries to compress records of size greater or equal to 128 bytes. If compression not gives sufficient economy, the record is storing not-compressed.
Is the compression similar to (or the same as) that used on tps records?
Generally, algorithms are similar: both are variants of RLE. But one used for QUEUEs is faster and as a rule produces better result because of preliminary optimization of data to be stored.