PureBasic Forums - English

Update on this topic:

I now tried for almost two weeks to reproduce the
IMA with the new PB 5.22 LTS with no success.
It seems that the bug has flown away.
I know, that the absence of occuring of an IMA
doesn't mean that it was fixed or was not a PB
problem, as nobody else could reproduce the IMA
and myself was not always able to get this be-
haviour appearing.
I will still have an eye on this.

P.S.
I didn't change anything on my machine except
installing new 5.22 LTS.
Previous versions (including 5.22 Betas) still throw
out this error. So I'm still convinced that this was
a PB bug.

Lord wrote:..
It seems that the bug has flown away.
...

Bad news. Nothing has flown away.
The bug is still there.

Hi,

try this: Maybe it helps.

Bernd

Hello Bernd!

Thank you for another helping hand.

Unfortunatly this way doesn't work either.
As the problem occured first in a much bigger program,
there were also a menu. I stripped it down and left
the keyboard shortcut because I could faster handle
it for testing.
The IMA occures with and without a menu.

The problem is, that I can not crash the application.

Have you tried the other way round?

Disabling some things in the program.
If you comment out the AddKeyboardShortcut for example.
Or comment out the OpenFileRequester.

Bernd

I mean:

Add a button insted of AddKeybordShortcut()

Use SaveFileRequester() instead of OpenFileRequester()

So maybe you can track it down a bit more.

infratec wrote:The problem is, that I can not crash the application.

Have you tried the other way round?

Disabling some things in the program.
If you comment out the AddKeyboardShortcut for example.
Or comment out the OpenFileRequester.

Bernd

Commenting out AddKeyboardShortcut and/or OpenFileRequester
seems to prevend the IMA to occur. Seems.
But without the shortcut there is no action at all, just opening
and closing a window.

infratec wrote:I mean:

Add a button insted of AddKeybordShortcut()

Use SaveFileRequester() instead of OpenFileRequester()

So maybe you can track it down a bit more.

Using a button instead of key didn't fire an IMA right now.
But that doesn't mean anything. I have to try some more
days as I already thought several times that I catched
the trouble maker.
Right now I "have the feeling" that the special character "ü"
in the file name forces the IMA as if I left out to open a file
with that character in filename the IMA doesn't occur.
But as the IMA occours that rare and randomly I can not
be sure for that.

Hi,

that was also my first thought, and I only used files with this german special characters.
But on Win 7 64 bit with PB 5.22 x86 I was not able to reproduce the fault.

I also changed the compileroption 'unicode'.

Bernd

infratec wrote:...
I also changed the compileroption 'unicode'.
...

Unicode or ASCII doesn't make any differnce.

I repeatedly tested your code on this and two other computers and still no luck with reproducing your experiences. I compiled using the different compilers versions you mentioned produced bad executables.

I used ged file with ü in the name.

I'm thinking perhaps faulty RAM is at play here. Have you ran thorough diagnostics on the RAM yet?

Btw; How large is your ged file?

Hi Thunder93!

Thunder93 wrote:I repeatedly tested your code on this and two other computers and still no luck with reproducing your experiences. I compiled using the different compilers versions you mentioned produced bad executables.
...

I'm also not always successful. It's rare and very random.

Thunder93 wrote:...
I'm thinking perhaps faulty RAM is at play here. Have you ran thorough diagnostics on the RAM yet?
...

No faulty RAM. I tested it several times and there are no other
"strange things" happening.

Thunder93 wrote:...
Btw; How large is your ged file?

For testing I created just empty text files and renamed tehm to *.ged.
My real GEDCOM files range from some KB up to 5 MB.

I've seen some cases where running non-PB applications causes problems. Running memory diagnostics on the memory yielded nothing (on x64 computers.) To do a real thorough diagnostics on the memory could be very time-consuming. I usually do the default aka standard type scan with Windows Memory diagnostics tool. Let it do six passes and If it found nothing by then, I troubleshoot the memory the classic-way.

Recently observed something strange, a memory in specific slot causes issues. Removing the memory and the problems existed no more. Inserting properly the memory back in, and testing, the problems returned. Then I thought I'd play around and switch the RAM around into different slots. Tested and not no problems. Move the RAMs back to their original positions and the problems returned.


Another messing around sort-of thing besides. What happens when you run your compiled demo code from memory card, or thumb drive? Have your .ged files also on the memory card / thumb drive and test.

Hi Thunder!

Thunder93 wrote:I've seen some cases where running non-PB applications causes problems. Running memory diagnostics on the memory yielded nothing (on x64 computers.) To do a real thorough diagnostics on the memory could be very time-consuming. I usually do the default aka standard type scan with Windows Memory diagnostics tool. Let it do six passes and If it found nothing by then, I troubleshoot the memory the classic-way.

Recently observed something strange, a memory in specific slot causes issues. Removing the memory and the problems existed no more. Inserting properly the memory back in, and testing, the problems returned. Then I thought I'd play around and switch the RAM around into different slots. Tested and not no problems. Move the RAMs back to their original positions and the problems returned.
...

Memory is thoroughly tested. No problem there.
And as I wrote here:
http://www.purebasic.fr/english/viewtop ... 2&start=19

Lord wrote: ...
At last, I could try the compiled code on a laptop from
a friend of mine.
Result: random crash.
...

So I think it is not really tied to my computer.

Thunder93 wrote:...
Another messing around sort-of thing besides. What happens when you run your compiled demo code from memory card, or thumb drive? Have your .ged files also on the memory card / thumb drive and test.

I did this when I got a hand on the Laptop mentioned above.
Result as stated above.
At this time I also run the code from USB stick on my machine
with files on stick also: IMA.

Very interesting experience you shared here.

I wonder what would have shown from having compiled your file from another machine? Then testing the compiled file on both systems that way.

I find it weird that we can't seem to reproduce your experiences even though we are mirroring your conditions.

You ran sfc and it returned ..did not find any integrity violations. Then you did a clean install of Windows 7 and before installing third-party software, you had tested your code and experienced the same thing.

0xC0000005 is the code for memory access violation.

This MAV just means that: the processor tried to read from or write to a particular address that its current state did not allow. Found several places on the web that actually pen-pointed it to be bad RAM. One very brief example.. http://www.tomshardware.com/forum/23945 ... -violation

However this MAV doesn't always mean its a hardware issue tho, however it could be a bus error, unmapped virtual memory, faulting CPU; pretty much anything that indicates violating access protections. Here is one interesting article - http://blogs.technet.com/b/askperf/arch ... e-you.aspx .. also take note regarding DEP.


The good thing is that you said there is no IMA with the latest PB. Maybe you guessed it correctly? However not always is it what it appears to be.

However that being said..., I won't be surprised if 0xC0000005 MAV shows up when running different PB generated code OR, running something entirely different.

Just sorry we couldn't have been more of an help here.

Thunder93 wrote:Very interesting experience you shared here.

I wonder what would have shown from having compiled your file from another machine? Then testing the compiled file on both systems that way.

I find it weird that we can't seem to reproduce your experiences even though we are mirroring your conditions.

You ran sfc and it returned ..did not find any integrity violations. Then you did a clean install of Windows 7 and before installing third-party software, you had tested your code and experienced the same thing.

0xC0000005 is the code for memory access violation.

This MAV just means that: the processor tried to read from or write to a particular address that its current state did not allow. Found several places on the web that actually pen-pointed it to be bad RAM. One very brief example.. http://www.tomshardware.com/forum/23945 ... -violation

However this MAV doesn't always mean its a hardware issue tho, however it could be a bus error, unmapped virtual memory, faulting CPU; pretty much anything that indicates violating access protections. Here is one interesting article - http://blogs.technet.com/b/askperf/arch ... e-you.aspx .. also take note regarding DEP.
...

I do not have the opportunity to compile the test code on another machine
and test the executable on my machine.
I once had the chance to run the exe on a laptop resulting in an IMA there too.

Regarding DEP. How could this small code snippet produce a DEP?

Thunder93 wrote:...
The good thing is that you said there is no IMA with the latest PB. Maybe you guessed it correctly? However not always is it what it appears to be.
...

It was not as it appeared:

Lord wrote:

Lord wrote:..
It seems that the bug has flown away.
...

Bad news. Nothing has flown away.
The bug is still there.

Thunder93 wrote:...
However that being said..., I won't be surprised if 0xC0000005 MAV shows up when running different PB generated code OR, running something entirely different.
...

It's weird. This is the only constellation, that I get an IMA constantly.
I did a lot of programs for myself. Of course, some times I had an IMA,
but I could finally sort them out.

Thunder93 wrote:...
Just sorry we couldn't have been more of an help here.

Thanks anyway.