Great problem with memory on ARMBE XScale IXP425 QNX 6.3 SP2

pvk · August 4, 2006, 1:36pm

There is a simple test:

#include <stdlib.h>
#include <stdio.h>

#define MALLOC_SIZE 1048576

int main(int argc, char *argv[]) {
char *ptr = NULL;
int n = 0;

while(1)
{
printf(“n=%d\n”, n++);
ptr = (char *)malloc(MALLOC_SIZE);
if(ptr)
{
printf(“ptr=%08x (%d bytes)\n”, ptr, MALLOC_SIZE);
//free(ptr);
}
else
perror(“malloc” ) ;
usleep(500000);
}

return 1;
}

My log was:

pidin info

CPU:ARM Release:6.3.0 FreeMem:54Mb/64Mb BootTime:Jan 01 00:00:00 UTC 1970
Processor1: 1761952193 ixp425 533MHz

mytftp

MYTFTP
n=0
ptr=00114018 (1048576 bytes)
n=1
ptr=0021c018 (1048576 bytes)
n=2
ptr=00324018 (1048576 bytes)
n=3
ptr=0042c018 (1048576 bytes)
n=4
ptr=00534018 (1048576 bytes)
n=5

That is all. THE SYSTEM WAS CRASHED !!!

Why?
I run this test on x86 - all was OK.

I asked a man to run this test on armle.
His log was:# pidin info
CPU:ARM Release:6.3.0 FreeMem:46Mb/64Mb BootTime:Jan 01 00:00:00 UTC 1970
Processor1: 1761946886 pxa250 400MHz

./malloc-test

n=0
ptr=00112018 (1048576 bytes)
n=1
ptr=0021a018 (1048576 bytes)
n=2
ptr=00322018 (1048576 bytes)
n=3
ptr=0042a018 (1048576 bytes)
…
n=27
ptr=01dcf018 (1048576 bytes)
n=28
ptr=01ed7018 (1048576 bytes)
n=29
malloc: Not enough memory
n=30
malloc: Not enough memory

And system was not crashed.

Why my test crashes the system???
What can i doing with it?
Can anybody run this test on ARMBE?
Please, help me!!!

Tim · August 4, 2006, 1:48pm

Mario,

I think PVK is saying that when his system ‘crashed’ that it really crashed as in locked up as opposed to just printing the out of memory error as it does on an x86 system.

I have no idea how memory management works on ARM processors so I am not sure what the problem could be.

One thing PVK didn’t mention was his setup or that of the other person. If he was remotely telneted into his target it’s possible that when he ran out of memory that it merely looked like a crash because telnet hung up because it couldn’t get any RAM that it might have needed.

Tim

pvk · August 4, 2006, 1:52pm

I connected to target via COM-port.

pvk · August 4, 2006, 2:01pm

Also i attempted to copy a big file (near 8 MB) to target via qconn from QNX Momentcis IDE.
Near 6 MB copied system was crashed.

mario · August 4, 2006, 2:50pm

Make sure you have 6.3.2 core update (I remember something about fix on ARM). Also have you consider the hardware could be bad.

maschoen · August 4, 2006, 6:43pm

Just a suggestion. Change the while loop to a for loop, and have it run just one or two more cycles then it usually takes to crash. This will confirm or eliminate the possibility that the crash is caused by the loop running away.

pvk · August 7, 2006, 5:15am

I have installed SP2.
How can i understand, that 6.3.2 core is updated?

I don’t find this fis in SP2.
Only this, but it is not this problem:
"What’s new: Core OS
malloc() optimizations
The standard C library malloc() has been reworked to improve performance for small allocations. "

I ran this test on Monte Jade IXDPG425, also on another board.
And in another QNX forum another man have this problem.

pvk · August 7, 2006, 5:33am

I have done many different tests, not only with malloc: creating/writing files, copying files via tftp, qconn.
And result was CRASH of system

pvk · August 7, 2006, 1:01pm

Is this only my problem?

mario · August 7, 2006, 1:38pm

6.3.2 is NOT included in SP2, it’s a separate update. I took a quick look at the release note but didn’t find anything about an ARM specific issued.
bad.

If you run qconfig it will tell you all the installed updated.

pvk · August 7, 2006, 1:47pm

Ok, this was my mistake.
I have downloaded and installed ntocore-6.3.2.

But this problem is not resolved

Yes, there is not anything about this problem.

pidin info

CPU:ARM Release:6.3.2 FreeMem:54Mb/64Mb BootTime:Jan 01 00:00:00 UTC 1970
Processor1: 1761952193 ixp425 533MHz

mario · August 7, 2006, 2:33pm

Then either it’s a bug with the kernel ( which I doubt for something so basic) or it could be the memory mapping that doesn’t match the physical layout of the memory.

Tim · August 7, 2006, 3:33pm

PVK,

Can you describe the crash of the system. In other words, what makes you think the system crashed? Do you see a Kernal fault displayed? Does the board auto-reset? Or something else?

Remember, if all the RAM is exhausted some very simple things like printf may stop working simply because they need some Ram they can no longer get. So it may be that the OS is in fact still running.

Determining when an OS exhausts all available memory is a tricky thing to do in practice unless you create memory pools for all utilities to ensure they can still report the out of Ram condition.

Tim

pvk · August 8, 2006, 5:21am

I directly connected to board via uart.
When i copying a big file via qconn or via tftp or create a big file, there was a message like this:
Shutdown[0,0] S/C/F=11/1/11 C/D=fe005fec/fe051ed0 state(1)= 1
[0]PID-TID=1-6? P/T FL=00019001/05020000 “proc/boot/procnto”
[0]ASPACE PID=12295 PF=00401010 “proc/boot/qconn”
armbe context[fe05ff78]:
0000: 00000000 00000006 fc404800 00000000 fe05bdc8 00000000 fe051ee0 fe0581c0
0020: 00000000 00000000 fe538000 fe05ffd8 fe05ffdc fe05ffbc fe032154 00112efc
0040: 20000013
instruction[00112efc]:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
stack[fe05ffbc]:
0000: fe05bdc8 fe0585a0 fe051ee0 fe0581c0 fe05fffc fe05ffdc fe032154 00112ef4
0020: 00000005 00000005 00000000 fe050d64 fe061080 fe069e84 fe060000 fe0615cc
0040: fe0320d8 00000000 fc404000 03ef9184 00000000 00000000 fc404000 03dc9628
0060: 00000000 00000000 fc404000 03f7452c 00000000 00000000 fc404000 03f75184

Tim · August 8, 2006, 2:14pm

PVK,

Yup, that sure looks like a Kernel dump all right

If you look in the help viewer and search for “kernel dump” you’ll see a nice little section on how to read it. Not that it will do much good of course.

All this tells you (S/C/F=11/1/11) is that you got a signal 11 (SIGSEGV) due to an Address Not Mapped error while qconn was running.

This seems to point to what Mario talked about with the memory mapping not matching the physical layout of the memory. Not sure how that helps much to solve it. Probably need to contact QNX tech support at this point or check all the options to the kernel for ARMBE and see if there are any memory options to be set.

Tim

mario · August 8, 2006, 2:26pm

I find it odd that the instruction is at address 0x00112efc, since the kernel seems to be located at address 0xfexxxxx and there is only 64M of ram that doesn`t add up.

Note that I`m not that familliar with interpreting kernel dump.

bkhlady · August 11, 2006, 8:29pm

Hi guys,

I’m not seeing the crash
n=27
ptr=01dd3018 (1048576 bytes)
n=28
ptr=01edb018 (1048576 bytes)
n=29
malloc: Not enough memory
n=30
malloc: Not enough memory
n=31
malloc: Not enough memory
n=32
malloc: Not enough memory
n=33
malloc: Not enough memory
n=34
malloc: Not enough memory

uname -a

QNX socrates 6.3.2 2006/03/16-14:15:30EST IXP_425 armbe

pidin info

CPU:ARM Release:6.3.2 FreeMem:53Mb/64Mb BootTime:Jan 01 00:00:00 UTC 1970
Processor1: 1761952193 ixp425 533MHz

Cheers,
-Brian

pvk · August 14, 2006, 6:02am

bkhlady

It’s very curiously.
The thame processor, the same OS…
Whar board do you use?

bkhlady · August 14, 2006, 12:08pm

Arcom Vulcan ICE. Which board is yours?

pvk · August 15, 2006, 4:41am

My board is Monte Jade IXDPG425.