Mahdi Safsafi

Indeed you're absolutely right. But the intention of the above solution I proposed was to be a temporary fix that doesn't use any external library. When he would have some time, he may need to investigate further for a suitable solution.

@dummzeuch Yes FastMM can handle it but OS provides much options(ZeroInit, FileMapping, ...). Besides the behavior when OS fails is very well documented. Anyway, there is no harm to use FastMM ... after all it will call OS functions. or temporary solution : var OriginalMemoryManager: TMemoryManagerEx; NewMemoryManager: TMemoryManagerEx; function NewGetMem(Size: NativeInt): Pointer; begin Result := OriginalMemoryManager.GetMem(Size); if not Assigned(Result) then raise EOutOfMemory.Create('Error Message'); end; begin GetMemoryManager(OriginalMemoryManager); NewMemoryManager := OriginalMemoryManager; NewMemoryManager.GetMem := NewGetMem; SetMemoryManager(NewMemoryManager); end.

Why you're using Delphi MM for such large block ? It would be better to use OS functions.

Yes it comes very handy and it would be much more powerful when it supports class inheritance check(ignoring all exceptions that descent from a particular class). One thing worth to mention, Thomas told me that he managed to make it works on all Delphi versions >= 2005.

@Kas Ob. Well I was referring to the decision. The chance to improve quality is higher when you only focus on one thing.

IMO, this is the right decision. What do you think guys ?

Good point Attila. It also makes comparing c code against Delphi code much easy.

Not IDA ... its x64dbg 🙂

I really don't know. Well I never tried to consume Delphi stuff from c/c++ mostly because c/c++ has a much native frameworks than Delphi ... However I do consume c/c++ stuff from Delphi.

Those are not stored inside vtable ... you need to skip them(don't declare them). Exactly! That's my bad man ... I'm a little bit bad at explaining since I'm not a native English speaker. First step, add all methods in the order they declared(skip all overloaded versions but keep the original). second step for each added method "A" add just after it "A" all its overloaded versions in the order they declared too. Here is how your vtable looks like.

Basically vtable respects the order in which functions are declared. But here the overloading is tweaking. Try to respect both the order and overloading name. The below code should demonstrate what I mean. // SetAttributeValue declared first ... we put it first function SetAttributeValue(name: LPWSTR; _type: D2D1_SVG_ATTRIBUTE_STRING_TYPE; value: LPWSTR): HResult; overload; stdcall; // then we put all overloaded methods SetAttributeValue but in the order they were declared: function SetAttributeValue(name: LPWSTR; _type: D2D1_SVG_ATTRIBUTE_POD_TYPE; value: Pointer; valueSizeInBytes: UINT32): HResult; overload; stdcall; // SetAttributeValue2 function SetAttributeValue(name: LPWSTR; value: ID2D1SvgAttribute): HResult; overload; stdcall; // SetAttributeValue3 // GetAttributeValue comes after SetAttributeValue: function GetAttributeValue(name: LPWSTR; _type: D2D1_SVG_ATTRIBUTE_STRING_TYPE; out value: PWideChar; valueCount: UINT32): HResult; overload; stdcall; // overloaded2 first and then overloaded3 function GetAttributeValue(name: LPWSTR; _type: D2D1_SVG_ATTRIBUTE_POD_TYPE; value: Pointer; valueSizeInBytes: UINT32): HResult; overload; stdcall; // overloaded2 function GetAttributeValue(name: LPWSTR; const riid: TGUID; var value: Pointer): HResult; overload; stdcall; // overloaded3 PS: I got the smile SVG 🙂

@pyscripter I believe you're wrong on $78 ! its for an overloaded GetAttributeValue function (not SetAttributeValue). So your code is calling an overloaded version of GetAttributeValue instead of SetAttributeValue.

Yes you're absolutely right ... I don't really know how the post ended like this. Anyway, it was really nice to have this little discussion with you. Thanks for your time and the valuable information/material you provide.

Secret ? no, they're publicly published (agner, intel/amd doc, optimization guide, paper, LLVM, ...). I read them and experiment things my self and when I have no things to do I compare results on different compilers. Sometime, when I'm lucky, I find an already benchmark that lists the results. Error happens a lot specially when porting code from/to another platform ... but I deeply inspects the error and try to learn from it : why it happened ? a workaround ? how to avoid it?.

Yes, I use several compilers (not limited to Delphi) and I can sadly tell you that Pascal compilers didn't evolved in a good way like other compilers. Its not about whether you like them or not. In fact for me, I don't find any issue using low level stuff pointer or assembly. But today, I try to be much wise and choose the best friendly way for the compiler. What are you missing is that today sophisticated compiler in many case can do better job than you can do by using low level stuff like assembly or pointer. gcc for example is able to recognize a pattern (while do) that calculates bits count and replace this loop by a single instruction. It can reorder things for you when it detects that you're misusing some functionality: see this SO. A compiler could generate much better code only when it can understood your code. If you manage to write a hard code that your compiler can't understand it wan't be optimized correctly. Here is a simple example to show what would happen when the compiler does not understand your code: both swap/swap2 function do the same job but one is decrementing i and the other one is incrementing i. and both log the result using a for loop. The interesting part is that unlike swap, the two loop of swap2 were merged together __declspec(noinline) void swap(short int* src, int* dst, int count) { short int* p = src; int* r = dst; int i = count; // loop 1 while (i--) { *r++ = swapint(*p++); } // loop 2 for (int i = 0; i < count; i++) printf("%d = %d\n", i, dst[i]); return ; } __declspec(noinline) void swap2(short int* src, int* dst, int count) { short int* p = src; int* r = dst; int i = count; // compiler merged/combined the two loop ! while (i++ != count) { *r++ = swapint(*p++); } for (int i = 0; i < count; i++) printf("%d = %d\n", i, dst[i]); return; } int main() { short int src[10] = { 1,2,3,4,5 }; int dst[10] = { 0 }; swap(&src[0], &dst[0], 10); swap2(&src[0], &dst[0], 10); return 0; }

WaitForDebugEvent function is called from the debug loop thread but DoShowException function is called from another thread. A fraction of eye before DoShowException is called, WaitForDebugEvent may receive a debug event exception which may override FDebugEvent variable and you may end up processing the new exception and missing the old one. Using a list of FDebugEvent will guarantee that for each exception, you have a valid associated FDebugEvent struct. I don't know if there is a better way to work around without using a list of FDebugEvent. If you find a better way, please let me know. Apart from that, are you making any progress ? did the non-WaitForDebugEvent-method worked for all new Delphi versions ?

I think that the right thing is to report it as a false positive at BD.

@pyscripter I just made a benchmark against Perl regex. Yes its weird to compare a compiler vs interpreter ... but Perl beats Delphi own & study regex. However it failed to bit jit regex. A script and detailed result are attached. Benchmark.rar

@pyscripter Here is the x86 function. But its really weird, the original version shipped with Delphi declares it as empty and it works. I don't understand why it crashed with you when you defined it as empty. @Kas Ob's point is very interesting. I didn't read the configuration's documentation. But he definitely did ... Perhaps he is right. I suggest that you check with him that point. And who knows ... you may not need to use chkstk. chkstk.txt

Wow ... that's a 100mb !

Yeah I know that, I early proposed to you to use MSVC for x64 and bcc32c for x86. Sadly bcc32c (at least the free version) is build on an old LLVM compiler. Good luck ! if you need some help let me know.

From what I understood from your comment, you're going to compile using MSVC and then use some tools to convert the output ? why not give bcc32c a chance ? if it does not work ... you can simply use plan B.

@pyscripter Anyway I compiled (using CLANG) a simple c code that I tweaked to use chkstk. and then I dumped the function and edited it to be compatible with Delphi : procedure chkstk(); asm .NOFRAME sub rsp, $10 mov [rsp], r10 mov [rsp+8], r11 xor r11,r11 lea r10, [rsp+$18] sub r10,rax cmovb r10,r11 mov r11, qword ptr gs:[$10] cmp r10,r11 db $f2 jae @@L1 and r10w,$F000 @@L2: lea r11, [r11-$1000] mov byte [r11],0 cmp r10,r11 db $f2 jne @@L2 @@L1: mov r10, [rsp] mov r11, [rsp+8] add rsp, $10 db $f2 ret end; EDIT: I didn't pay attention to the GAS syntax for branch and interpreted it as hex ... My bad.

I'd help ... I'm just checking other options.

Yes disabling stack check will not suppress ___chkstk_ms. Only /GsX will do provided that this option is supported by your compiler and X is higher than probe size. Now. are you sure that the crash comes from ___chkstk_ms ? also have you disabled other runtime check ?