Access violation in Wimbledon sim

This one reads "Access violation at address 00525343 in module 'SimSigLoader.exe' Read of address 00000020"

Clive,
The message was cut and paste from what was on the screen so it must be correct. As I said I have had access violation messages crop up previously whilst inputting details for this timetable that I am writing. I now have over a thousand movements inputted.
I don't think it right to just keep on accepting and ignoring the messages I am getting without having someone explore the reasons why, so when it happens again I will cut and paste that one and post in the forum for someone to look at.

Geoff

Is there some sort of underlying problem with the loader that is causing it to do things you are not expecting?

Exception in OneSecondLo (EAccessViolation: Access violation at address 00442C76 in module 'SimSigLoader.exe'. Read of address 00000074)

Clive,
The message was cut and paste from what was on the screen so it must be correct.

As I said I have had access violation messages crop up previously whilst inputting details for this timetable that I am writing. I now have over a thousand movements inputted.
I don't think it right to just keep on accepting and ignoring the messages I am getting without having someone explore the reasons why, so when it happens again I will cut and paste that one and post in the forum for someone to look at.

What seems inconsistent, Clive? 0x00525343 is a valid instruction in V4.3.2 of SimsigLoader.exe.

The attempt to access memory address 0x00000020 looks awfully like a memory pointer isn't being properly initialised (or is being unexpectedly overwritten).

(At that, 0x00442C76 also exists in V4.3.2)

Edit: I wonder if your debugger is showing addresses beginning at the same offset as mine is (and presumably the error messages)? The first instruction in mine is at address 0x00401000.

How about this one Clive....just appeared on the screen......

"Access violation at address 400068A0 in module 'rtl60bpl'. Write of address 40341DFA"

This is getting a tad annoying having these messages keeping appearing on the screen.

Perhaps I should forget about ever writing a timetable, but considering the amount of time I have put in on this one it does seems a terrible waste if I do.

Did the problems/messages with Feltham that I reported get sorted and will the loader be updated sometime soon with the fixes for those messages.

1: The address has been reported wrongly. That's certainly happened in the past: I had a report of a problem at address (let's say) 00456789 with a read of address 00000048. When I look, that's not a valid instruction address. But if I look at address 00456987 instead, I find an instruction with a +48 in it, in the middle of code related to the reported symptoms. Therefore I assumed the original reporter had given the wrong address.

2: The Delphi error handling mechanism is giving the wrong address sometimes. If so, I don't know why, because it very often gives the right address.

3: The address is correct because the underlying problem caused a jump to an invalid address (e.g. by corrupting the stack) which happened to decode as an instruction that caused this symptom. If this is so, then looking at the code isn't going to point out the problem. What I need is instructions on how to consistently recreate the problem. I can then investigate the related code, run things under a debugger, and so on.

" said:

How about this one Clive....just appeared on the screen......

"Access violation at address 400068A0 in module 'rtl60bpl'. Write of address 40341DFA"

rtl60bpl is Delphi support stuff. If I track down that address it will be something like the code for joining two strings together. Unless it can be made repeatable I don't know how to investigate it.

I'm also not sure why only you are getting all these problems. What kind of system are you running? Have you tried uninstalling and reinstalling the system files? (Yes, I'm clutching at straws.)

Quote:

This is getting a tad annoying having these messages keeping appearing on the screen.

I'm not surprised you feel like that and I sympathise.

Quote:

Perhaps I should forget about ever writing a timetable, but considering the amount of time I have put in on this one it does seems a terrible waste if I do.

Please carry on. At best, perhaps you can come up with a pattern of actions that triggers the issues, so that Geoff and I can investigate.

Quote:

Did the problems/messages with Feltham that I reported get sorted and will the loader be updated sometime soon with the fixes for those messages.

Can you give me a Mantis number? Or failing that a pointer to the relevant thread?

Quote:

Edit: I wonder if your debugger is showing addresses beginning at the same offset as mine is (and presumably the error messages)? The first instruction in mine is at address 0x00401000.

Mine begins:

//import function kernel32.GetModuleHandleA(lpModuleName:PAnsiChar):HMODULE; stdcall;
00401498 jmp dword ptr ds:[568928]
//---------------------------------------------------------------------------
//procedure InitializeModule; stdcall;
004014A0 mov eax,55B000; Module:System.TLibModule
004014A5 call RegisterModule
004014AA ret


It often gets the code right for an address, as I've described before. So I'm a little puzzled.

In which case would it help if the reporter indicated whether the address was entered by copy and paste so unlikely to be incorrect or manually entered?

Quote:

2: The Delphi error handling mechanism is giving the wrong address sometimes. If so, I don't know why, because it very often gives the right address.

Would that suddenly give rise the number of times that this sort of problem has been reported recently where previously reports have been rare?

If you haven't already got that from me, I can let you have a saved game where the problem I reported occurs every time it is run.

When working on other projects, I found that errors such as this were often made to trigger register/stack dumps to a file and (in some cases) full memory dumps. If this is possible with Delphi, perhaps enabling this for a future release would be a really good idea, to make debugging much easier in cases where stack corruption has occurred.

I am not sure if I am being treated as the lone soldier here. The comment above about me being the only one having these problems is totally without foundation. I can see at least three other persons in this thread alone that have chosen to comment and admit that they have had similar problems and reported them.

What is better, to get the error message or warning and just click and accept it and then carry on as though nothing had happened, or try and seek out a reason as to why it is happening and thus eliminate the chances of it happening again. I fancy that if other people who have attempted to write timetables for the various loader sims were to be truthful and admit that some of them had experienced similar problems then you might get the full story. I think it might be true that some of them have just pressed accept and carried on. Not really a good thing to do if it is affecting what the end user may get.

As reported in my query/similar problems with the Feltham sim I am using a HP Envy computer with the supplied Windows 8 operating system. Nothing fancy with additional screens or non paid for software, just what came off the shelf from the local John Lewis at Brent Cross.

Curious indeed! Those instructions start at 004014C8 for me, with the preceding lines being a large list of pointers to rtl60 functions, which are called from various locations in the code later on.

I wonder if this differing behaviour might be caused by how the program and the relevant libraries are loaded by different operating systems, versions of the Delphi libraries, and so on?

Please put it in Mantis (as a core code issue) and assign it to me.

" said:

I wonder if this differing behaviour might be caused by how the program and the relevant libraries are loaded by different operating systems, versions of the Delphi libraries, and so on?

Hmm. I wonder if that's the difference between Windows 7 and Windows 8? That's something to look into.