Exception in pocc.exe

[John Z]

Hi Master Sunshine!

Exceptional work.  I have no clue how you figured this out, but really fantastic.  Can't wait to hear more results from 24H2 capable testers.

Frankie - Is it possible that this alignment issue might play a role in the occasional mystery 64 bit compiler issue we experienced? 

John Z

Update - Unfortunately it does not, tested with a known offender file, same error
fatal error: Internal error: 'Access violation' at 0x00007ff6de183e99. . . . . NEW
fatal error: Internal error: 'Access violation' at 0x00007ff6de183e99. . . . . OLD

[sunshine]

If this patch does not work well on your computer, please give me a minimal piece of code that can reproduce the problem, and also your OS version, I will try to analyze it again.

[John Z]

Hi Sunshine,

Oh the patch is working I'm sure and in any case I'm on WIN 23H2 which does not show the issue.
I was just trying the patch to see if it affected a 64 bit build that causes the aforementioned error.

Most 64 bit program compile nicely, but a few run into the Access violation error.  In some cases rearranging the code can remove the access violation but it is hit and miss.  The 32 bit build of the same code never has an issue.

John Z

[HellOfMice]

Mr SunShine


Here Rainy day


I think it is more complicated and your analyze is too simple.
First Why when compiling for a console project no problem met?
Second Why when compiling many asm files sometimes I never have the problem and sometime I have it?
I have a project with 7 asm files and 2 c files, I always have the proablem with poasm and not pocc!
When compiling under cmd I NEVER have problem.
I don't think that pelles has a bug. I met this bug many years ago and spoke about in this forum
Thank you for your researches. When I debug into poedit that creates problems under notepad++, nor poedit, not Notepad++ have bugs for this but the environment give them wrong datas. Me I too I search but no success.

[HellOfMice]

The problem always exist with pomake launched from poedit
if pocc or poasm where the problem it would always exist whereever it is used, une der poedit or under a dos box (cmd)
A good test would be to rename pomake and create a batch file by hand for compiling a whole project and see...

[HellOfMice]

Have a look

******************************
*** Cleaning project files ***
******************************
************************
*** Building RELEASE ***
************************
*********************************
*** Compiling Assembler files ***
*********************************
*************************
*** Compiling C files ***
*************************
*********************************
*** Compiling Resources files ***
*********************************
*********************
*** Linking files ***
*********************
POLINK: warning: Realigned section '.idata$5' in object 'sqlite3.lib(sqlite3.dll)' (from 4 to 8 byte(s)).
POLINK: warning: Realigned section '.idata$4' in object 'sqlite3.lib(sqlite3.dll)' (from 4 to 8 byte(s)).
*********************
*** Project Built ***
*********************
Appuyez sur une touche pour continuer...

Poasm & pocc are ok

Just one compilation a file present into the previous project

> poasm.exe -AAMD64 -Zi -Gz -FlDebug.lst -Fo"C:\Users\51966\Documents\DocsPhR\# Assembleur\Awpe\Compile\F0000.obj" "C:\Users\51966\Documents\DocsPhR\# Assembleur\Awpe\F0000.asm"
warning: Ignored in 64-bit mode: 'STDCALL'.
*** Error code: -1073741819 ***
Done.

Tghe problem is before compiling

[TimoVJL]

I can simulate a make


POCC Something.c
IF ERRORLEVEL 1 GOTO FINISHED
POASM Another.asm
IF ERRORLEVEL 1 GOTO FINISHED
POLINK ...
IF ERRORLEVEL 1 GOTO ERRORLINKER
MYPROGRAM.EXE
EXIT
:ERRORLINKER
ECHHO You are bad
:FINISHED
EXIT

this example don't even check return value -1073741819 ?
poide.exe print just every return value.

[HellOfMice]

Yes do it and we will show, like in my batch file bellow

[alderman2]

I found a solution that seems to fix this problem. By patching pocc.exe to enlarge the stack frame of one of the functions on the problematic call path by 8 bytes, then the memory addresses are aligned correctly.

You can use the pocc.exe patched by me or patch it by yourself. For version 12.0.1.0, only two bytes need to be modified.

First, at file offset 0x20ae64, change 0x20 to 0x28.
Second, at file offset 0x20ae8c, change 0x20 to 0x28.

It works but it goes slower.

[TimoVJL]

I found a solution that seems to fix this problem. By patching pocc.exe to enlarge the stack frame of one of the functions on the problematic call path by 8 bytes, then the memory addresses are aligned correctly.

You can use the pocc.exe patched by me or patch it by yourself. For version 12.0.1.0, only two bytes need to be modified.

First, at file offset 0x20ae64, change 0x20 to 0x28.
Second, at file offset 0x20ae8c, change 0x20 to 0x28.

It works but it goes slower.

Interesting 
In Windows 7 no difference

Code: [Select]

@ECHO OFF
SET INCLUDE=C:\code\PellesC12\include\Win;C:\code\PellesC12\include
@_RunCmdTime.exe C:\code\PellesC12\bin\pocc.exe -Gz -Ze -Zx -W0 C:\code\PellesC\TLPEView\TLPEView.c > NULL
ECHO.
ECHO Patched
@_RunCmdTime.exe pocc.exe -Gz -Ze -Zx -W0 C:\code\PellesC\TLPEView\TLPEView.c > NULL
ECHO.
@_RunCmdTime.exe C:\code\PellesC12\bin\pocc.exe -Gz -Ze -Zx -W0 C:\code\PellesC\TLPEView\TLPEView.c > NULL
ECHO.
ECHO Patched
@_RunCmdTime.exe pocc.exe -Gz -Ze -Zx -W0 C:\code\PellesC\TLPEView\TLPEView.c > NULL
ECHO.
PAUSE

BuildTime Add-In

[sunshine]

Hi Sunshine,

Oh the patch is working I'm sure and in any case I'm on WIN 23H2 which does not show the issue.
I was just trying the patch to see if it affected a 64 bit build that causes the aforementioned error.

Most 64 bit program compile nicely, but a few run into the Access violation error.  In some cases rearranging the code can remove the access violation but it is hit and miss.  The 32 bit build of the same code never has an issue.

John Z

Hi John,

According to my recent research, pocc has a special optimization for functions such as exit, _Exit, and abort. It uses the JMP instruction to replace the CALL instruction, but does not align the function stack frame. This problem affects the toolchain and runtime library. I patched several tools that did not work properly and patched all the places that seemed to have problems in the runtime library. Of course, only the 64-bit version needs to be patched. Especially, I patched pocc, let it emit some instructions to align the stack pointer before jump to functions like exit, _Exit and abort. So the user code can call these functions without an access violation. You may find my latest patched version on the GitHub. https://github.com/fengyoulin/pellesc

After all, I don't have the source code. I can only make small patches based on these binaries. This may not completely solve the problem, or may introduce new problems. I'm doing all this just in the hope that the tool will be usable until Pelle releases his next version.

Good luck to Pelle. Good luck to us.

[HellOfMice]

Thank You to search to solve this problem.
Take care of call, I often use jump rather than call

Code: [Select]

mov      rdx,WM_CLOSE
xor      r8,r8
xor      r9,r9
lea      rax,@Eoj + rip
push   rax
jmp      SendMessage
;   =====================================================

[HellOfMice]

In France we have a proverb which says that no one is held to the impossible

[CandCPlusPlus]

Did the February Patch Tuesday update for Windows 11 version 24H2 fix the problem? A bunch of bugs were fixed in the update.

[CandCPlusPlus]

You may find my latest patched version on the GitHub.

Could you post the source code and/or steps for patching the files? There is security implications with downloading executable files from a random location on GitHub and using the files. I imagine some users on here may not be comfortable with doing that.