Am Tuesday, 30. May 2006 22:19 schrieb Martin Kuball:
Am Monday, 29. May 2006 23:43 schrieb tim Rowledge:
On 29-May-06, at 12:51 PM, Martin Kuball wrote:
I examined the arguments to longAtput and they seem OK. But there is no Memory mapped at sqMemoryBase. How could that happen?
Martin
Forgot to give you some more details. I'm running a amd64 system with linux 2.6.14. Compiler ist gcc 4.0.3.
If there is no memory mapped at a fundamental address like sqMemoryBase that implies to me that some very serious has failed, and I think it must surely have failed right at the beginning of starting Squeak. You didn't mention anything about whether the system started up or not, what you were doing, or anything that might help us.
sqMemoryBase is typically set right at the beginning of the VM startup, by allocating the memory for the image so if for some strange reason that fails you could be in trouble. It's hard to imagine how the allocate could fail and not be detected though.
Hi!
I compiled a VM with BallonEngine, BitBlitSimulation and FilePlugin. I started the vm in gdb and checked the allocation of the memory. All went well. The reason I reported a bad memory region earlier is that sqMemoryBase is the real base - 16. Now the interpreter loop runs and at its 12th cylce (opcode 134) I still get the SIGSEV. Further investigation showed that foo->stackPointer is the culprit. All the cycles before it had a value of 15723512. But this time the value is 1509280732. Really bad. I will try to find out where this change happens tomorrow.
The only thing I can tell you is that the stackpointer is set from localSP at one point via: foo->stackPointer = oopForPointer(localSP); Now oopForPointer seems to be a simple cast to sqInt (which is a typedef from int). Now casting a pointer to a char to an int might actually leed to problems on a 64bit system. Which indeed it does in this case as 0x2aaaad732bec becomes 0xffffffffad732bec.
Any suggestions what to do now?
Martin