Bug and Access Violations

[Kobold]

Hi 

Attached is a small file (no dependencies) that demonstrates 2 bugs in Pelles C 11/12.

First is a false warning #2272: '0' is not a member of 'TestEnum (aka enum (no name))'

Second is one of many access violations I encountered in an attempt to port Jagged Alliance 2 to Pelles C.
I guess it's the same problem in most cases, so fixing this specific compiler bug should fix the problem in general.

Please read the comments for details.

I compiled everything in the IDE, didn't test if there is a difference when compiling from the shell.

Thanks for looking into it. Have a nice day.

[frankie]

Hello Kobold.
The enum test in your example doesn't produce any warnings. The following patched code does:

Code: [Select]

typedef enum
{
EOPTION0=1, //Don't produce any member == 0
EOPTION1,
EOPTION2,
EOPTION3,
EOPTION4,
EOPTION5,
EOPTION6,
ENUMOPTIONS
} TestEnum;

TestEnum e = 0;        //Warning is issued here.
In any case the value 0 is not strictly a member of the enum, and it is just a warning, you can disable it using pragmas.
IMHO the abuse made in many codes to force enum values that are not declared in the enumeration should be an error, why you use an enumeration if then you use arbitrary values? Just define an integer and some constants... 

For the assembler part confirmed the bug.
Just commenting the line:

Code: [Select]

RightSkipLoop: // skip along until we hit and end-of-line marker
Produce an error, and the warning about to limited portability of assembler code, but not crash with 'fatal error: Internal error: 'Access violation' at 0x00.........'. This means that the problem is at code generation or optimization level.

[Kobold]

The enum test in your example doesn't produce any warnings.

Here's the exact output I get in the IDE:

Code: [Select]

Building ja2_crash.obj.
D:\Dev\Projekte\JaggedAlliance2\ja2_crash.c(31): warning #2272: '0' is not a member of 'TestEnum (aka enum (no name))'
D:\Dev\Projekte\JaggedAlliance2\ja2_crash.c(32): warning #2272: '0' is not a member of 'TestEnum (aka enum (no name))'
fatal error: Internal error: 'Access violation' at 0x000000013f3db492.
*** Error code: 1 ***
Done.

Of course I could disable the warning. But I can't trust that the correct code was produced, the warning message makes me believe that it didn't interpret the code correctly and assumes a '0' where there is none.

[Kobold]

why you use an enumeration if then you use arbitrary values?

As stated in the source comments, this is not a real-world example. It is based on real code that produced the warning, and I quickly hacked it together for demonstration of the problem. I don't want anyone to download and compile a giant project just to get my point across

There should be no "member of enum" check involved here in the first place. It doesn't matter where ENUMOPTIONS comes from, it is just substituted by a number used to set the size of an array, the array itself doesn't need to have any interrelation with the enum type definition.

[frankie]

Of course I could disable the warning. But I can't trust that the correct code was produced, the warning message makes me believe that it didn't interpret the code correctly and assumes a '0' where there is none.

Your concerns are shareable, the problem for me is that I don't get the error:

Code: [Select]

Building ja2_crash.obj.
C:\ja2_crash\ja2_crash.c(74): warning #2007: Inline assembly code is not portable.
fatal error: Internal error: 'Access violation' at 0x00007ff6df939cf0.
*** Error code: 1 ***
Done.
Are you using the last compiler version?
Are you sure that there are no installation problems on your machine? 

[Kobold]

Are you using the last compiler version?

No, I wasn't. Been switching between 11 and 12 several times in the last few days.

Just tried with 12.0:

Code: [Select]

Building ja2_crash.obj.
fatal error: Internal error: 'Access violation' at 0x00000001401a9cf0.
*** Error code: 1 ***
Done.

I don't get that portability message.
Please note that I'm compiling a 32bit target. However, I got access violations on my main project (64bit) with 12.0, too. That's why I went back to 11.0.

That enum bug seems to be fixed in 12.0.

[frankie]

I don't get that portability message.

Enable Level2 warnings.

Please note that I'm compiling a 32bit target. However, I got access violations on my main project (64bit) with 12.0, too. That's why I went back to 11.0.

I'm compiling for 32bits too, in 64 bits mode inline assembler isn't allowed. You should get this error (not access violation!):

Code: [Select]

Building ja2_crash.obj.
C:\ja2_crash\ja2_crash.c(74): fatal error #2206: No support for inline assembly code on this target machine.
*** Error code: 1 ***
Done.
Please check again your installation.
You may want remove PellesC, remove directories by hand, clean registry keys, then make a fresh install.

That enum bug seems to be fixed in 12.0.

Infact it is 

[Kobold]

Please check again your installation.

In Reply #4 you confirmed the access violation with your installation. So the problem is not in my installation, it's in the compiler.

I have some more code that causes access violations when compiling.
Some functions with and some without inline assembly, some for 32bit, some for 64bit.
If the snippet from my original post isn't enough to locate the bug I might provide some more examples.

[frankie]

Yes Kobold the compiler is buggy. That inline assembler crash the compiler.
But inline assembler is allowed only for 32bits code.
I understood that eventually you were able to compile inlined assembler code in 64 bits mode. For this reason I asked to recheck the installation.
About finding the bug only Pelle can debug sources... I think that this sample is enough... 

[John Z]

Hi Kobold,

No, I wasn't. Been switching between 11 and 12 several times in the last few days.

Are you using two different computers for v11 vs b12, or are you doing complete uninstall and reinstalls?

John Z

[TimoVJL]

It is possible to use several versions of poide same time.

/x Turns off the 'single instance' check. [4.00]
/xml Stores all personal settings in the specified XML-file. [5.00]

I have used those options many years.

That feature was for beta testing and it is very useful.

[Kobold]

Are you using two different computers for v11 vs b12, or are you doing complete uninstall and reinstalls?

I'm just overwriting the installation. No uninstall, just run setup.exe for v11 or v12. It will just rebuild the database after install, so it's a matter of a few seconds to switch between versions.

I could also use different installations in VirtualBox, but the installation is not the problem here


In another project I managed to fix an access violation by changing the "Diagnostics" from "Classic" to "Caret". Unfortunately it doesn't help for the JA2 project.
Maybe that's a hint in the right direction? Pelle?

[Vortex]

Sandboxie is another nice option to test applications :

https://sandboxie-plus.com/

[John Z]

Thanks Kobold,

I'm just overwriting the installation. No uninstall, just run setup.exe for v11 or v12. It will just rebuild the database after install, so it's a matter of a few seconds to switch between versions.

This is what I was wondering if you had a way to maintain both database builds   But as you say the install is fairly quick.

Welcome to the forum BTW.

John Z

[Pelle]

I'm 200% confused. Ignoring this noise.