Re: g++, strange behavior issues

Dear Larry and all,

many thanks for your kind reply,

i enabled all the kernel debug / dump support options i found, but still 
my application, together with the kernel, locks silently, blocking the 
whole system without any message. Once the system is locked, i don't 
have any network or console access anymore.

/var/tmp # cat /proc/buddyinfo
Node 0, zone      DMA      1      6     16      5 3      5      3      
1      0      0      1
/var/tmp #

My application in c++ has now about 500K, shouldn't be a memory space 
problem.

/var/tmp # ls
cfbm   jffs2
/var/tmp # ls -al
drwxr-xr-x    3 root     0            1024 Jan 14 17:36 .
drwxr-xr-x    6 root     0            1024 Jan 14 17:27 ..
-rwxr-xr-x    1 root     0          580956 Jan 14 17:36 cfbm
drwxr-xr-x    6 root     0               0 Jan  1  1970 jffs2
/var/tmp # cat /proc/meminfo
MemTotal:          13560 kB
MemFree:            5988 kB
Buffers:              28 kB
Cached:              724 kB
SwapCached:            0 kB
Active:              128 kB

/var/tmp # ./cfbm
s 1
s 2
s 3
s 6

After launching the app, i just see some traces i "cout" and then the 
whole system stops.
Some time i see "s6" trace, some time "s3"only.

Strangely, i never had any issue with C apps until now, but they are 
generally much smaller.

Regards,
Angelo




On 24/01/2014 22:50, Larry Baker wrote:
> Angelo,
>
> My most frustrating experience with uClinux was with the memory 
> allocator.  Linux uses a "buddy" system power-of-2 allocator.  It is 
> VERY easy to fragment memory such that no more can be allocated. 
>  Usually I received an error message, which you say does not happen 
> for you.  Perhaps that is because in my case, the memory allocation 
> failure occurs during program loading, while yours occurs during 
> program execution (C++ startup vs. a plain C program?).
>
> The current memory free list is in .  Memory is organized into blocks 
> by powers-of-2.  The first one is the 2^0 * PAGESIZE.  PAGESIZE is 
> 4096 on x86 systems.  To find out the PAGESIZE, try "getconf PAGESIZE" 
> or "getconf PAGE_SIZE" (unless someone on the list knows what it is 
> for a coldfire mcf5307).  Even if there are, for example, 6 MB free 
> memory and your program only needs 5 MB, you won't be able to run your 
> program, because the next higher power-of-2 is 8 MB.
>
> Maybe this is what is happening to you.  I moved on to using SoC ARM 
> chips with lots more RAM and MMUs because I was wasting so much time 
> trying to squeeze a program to fit in an uClinux system.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> [email protected] <mailto:[email protected]>
>
>
>
> On 23 Jan 2014, at 2:31 PM, Angelo Dureghello wrote:
>
>> Dear Larry,
>>
>> many thanks for the very useful info, unfortunately i have still not 
>> solved.
>>
>> Original stack size in the header was 4096, i set it up growing until 
>> 65535, same result, program block and paralize the uclinux system 
>> without any wanring.
>>
>> I have some doubt,
>> 1) for example about the fact that i see that ti have compiled 
>> uclinux with CodeSourcery toolchain (i did it some time ago don't 
>> remember exactly the reason now), can this be an issue ? Anyway, 
>> actually i am compiling my c++ program with this same toolchain (gcc 
>> 4.6.1).
>> 2) could i have some uclinux configuration issues ? In particular i 
>> have doubt on general setup and processor
>>
>> General Setup:
>>  [*] Prompt for development and/or incomplete code/drivers
>>  ()  Cross-compiler tool prefix
>>  ()  Local version - append to kernel release
>>  [*] Automatically append version information to the version string
>>  [*] System V IPC
>>  [ ] POSIX Message Queues
>>  [ ] BSD Process Accounting
>>  [ ] Export task/process statistics through netlink (EXPERIMENTAL)
>>  [ ] Auditing support
>> RCU Subsystem  --->
>>  [ ] Kernel .config support
>>  (14) Kernel log buffer size (16 => 64KB, 17 => 128KB)
>>  [ ] enable deprecated sysfs features to support old userspace tools
>>  [ ] Kernel->user space relay support (formerly relayfs)
>>  [ ] Namespaces support
>>  [ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support
>>  [ ] Optimize for size
>>  [*] Configure standard kernel features (for small systems)  --->
>> Kernel Performance Events And Counters --->
>>  [ ] Enable VM event counters for /proc/vmstat
>>  [*] Enable SLUB debugging support
>>  [*] Disable heap randomization
>> Choose SLAB allocator (SLUB (Unqueued Allocator))  --->
>>  [ ] Allow mmapped anonymous memory to be uninitialized
>>  [ ] Profiling support
>> GCOV-based kernel profiling  --->
>>
>>     CPU (MCF5307)  --->
>>  [*] Enable setting the CPU clock frequency
>>  (90000000) Set the core clock frequency
>>  (2)   Set the core/bus clock divide ratio
>>  [ ] Old mask 5307 (1H55J) silicon
>>  *** Platform ***
>>  [*] Sysam AMCORE board support
>>  [ ] Arnewsh 5307 board support
>>  [ ] Motorola M5307C3 board support
>>  [ ] SnapGear SecureEdge/MP3 platform support
>>  [ ] Feith CLEOPATRA board support
>>  [ ] SecureEdge/NETtel board support
>>  [*] Support for U-Boot command line parameters
>>  [*] Use 4Kb for kernel stacks instead of 8Kb
>>  *** RAM configuration ***
>>  (0) Address of the base of RAM
>>  (0x1000000) Size of RAM (in bytes), or 0 for automatic
>>  (0x0) Address of the base of system vectors
>>  (0x20000) Address of the base of kernel code
>>  RAM bus width (AUTO)  --->
>>  *** ROM configuration ***
>>  [ ] Specify ROM linker regions
>>  Kernel executes from (RAM)  --->
>>  Preemption Model (No Forced Preemption (Server))  --->
>>  Memory model (Flat Memory)  --->
>>    (1) Turn on mmap() excess space trimming before booting
>>
>> Do you see something strange here ?
>>
>> I go on investingating,
>>
>> Many thanks,
>> angelo
>>
>>
>>
>> On 23/01/2014 19:49, Larry Baker wrote:
>>> Angelo,
>>>
>>> This sounds like your application stack size is too small and you 
>>> are overflowing the stack.  Remember, uClinux has no MMU to protect 
>>> for that.  Try increasing the stack size.  Ted Ma told me once the 
>>> application flthdr can manipulate the stack size in the executable's 
>>> header:
>>>
>>>> Hi Larry,
>>>>   flthdr is the utility to manipulate the header
>>>> ====
>>>> The flat format also defines the stack size for an application as a 
>>>> field in the flat header. To increase the stack allocated to an 
>>>> application, a simple change of this field is all that is required. 
>>>> This can be done with the flthdr command, like this:
>>>> flthdr -s  flat-executable
>>>>
>>>> The flat format also allows two compression options. The entire 
>>>> executable can be compressed, providing maximum ROM savings. It 
>>>> also offers the often useful side effect that the application is 
>>>> loaded entirely into a contiguous RAM block. You also may choose 
>>>> data-segment-only compression. This is important if you want to 
>>>> save ROM space but still want the option to utilize XIP. The following:
>>>>
>>>> flthdr -z flat-executable
>>>>   creates a fully compressed executable, and
>>>>
>>>> flthdr -d flat-executable
>>>>   compresses only the data segment.
>>>> ====
>>>>                               ...MaTed
>>>
>>> Larry Baker
>>> US Geological Survey
>>> 650-329-5608
>>> [email protected] <mailto:[email protected]>
>>>
>>>
>>>
>>> On 23 Jan 2014, at 1:15 AM, Angelo Dureghello wrote:
>>>
>>>> Dear all,
>>>>
>>>> i have a small board with a coldfire mcf5307, 4 MB flash and 16MB 
>>>> sdram.
>>>>
>>>> I have loaded on it this ucLinux:
>>>>
>>>> ~ # cat /proc/version
>>>> uClinux version 2.6.36.2 (angelo@angel3) (gcc version 4.6.1 
>>>> (Sourcery CodeBench Lite 2011.09-23) ) #122 Fri Dec 14 23:52:01 CET 
>>>> 2012
>>>>
>>>> I am now trying to upload and run a simple c++ program, with just 3 
>>>> simple classes,
>>>> and a main().
>>>>
>>>> Fist issue,
>>>>
>>>> I tried to use the most recent uclinux.org <http://uclinux.org/> 
>>>> supplied toolchanin (m68k-uclinux-20101118),
>>>> i get :
>>>>
>>>> make
>>>> /usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall 
>>>> -c -o obj/base64.o src/base64.cc
>>>> /usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall 
>>>> -c -o obj/main.o src/main.cc
>>>> /usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall 
>>>> -c -o obj/sha256.o src/sha256.cc
>>>> /usr/local/bin/m68k-uclinux-g++ obj/base64.o obj/main.o 
>>>> obj/sha256.o -m5307 -o bin/cfbm -Wl,-Map,bin/cfbm.map
>>>> ERROR: text=0x1c100 overlaps data=0x0 ?
>>>> collect2: ld returned 1 exit status
>>>> make: *** [bin/cfbm] Error 1
>>>>
>>>> Surfing the net, i don't find any good explaination to this, and 
>>>> the common workaround
>>>> suggested is to use the CodeSourcery toolchain.
>>>> So as a first thing i was wondering if the uclinux "user" folder 
>>>> does contain some cpp
>>>> projects, how do they compile ?
>>>>
>>>> Then i moved to the CodeSourcery toolchain, that i copied from an 
>>>> old hard disk, since
>>>> seems is not free to download anymore, is it ? Are there any 
>>>> alternative ?
>>>>
>>>>
>>>> With this toolchain strange things happen, until a certain point, 
>>>> adding code, everything
>>>> works fine, program is correctly compiled on my host and executed 
>>>> on the board. Then,
>>>> strangely, as the code increase, the program execution crash 
>>>> (without errors on console)
>>>> and paralize the system. As i remove (comment out) some lines, ini 
>>>> random places, program
>>>> start to work correctly again.
>>>> So for now, also the CodeSourcery toolchain solution is not helping me.
>>>>
>>>> I have now the suspect that uClinux itself has not been correctly 
>>>> configured, or that i am
>>>> suffering for my 16MB of ram, even if i see 6,8MB still free before 
>>>> executing.
>>>>
>>>> ~ # cat /proc/meminfo
>>>> MemTotal:          13684 kB
>>>> MemFree:            6984 kB
>>>> Buffers:              16 kB
>>>> Cached:              144 kB
>>>> SwapCached:            0 kB
>>>> Active:               64 kB
>>>> Inactive:             48 kB
>>>> Active(anon):          0 kB
>>>> Inactive(anon):        0 kB
>>>> Active(file):         64 kB
>>>> Inactive(file):       48 kB
>>>> Unevictable:           0 kB
>>>> Mlocked:               0 kB
>>>> MmapCopy:            412 kB
>>>> SwapTotal:             0 kB
>>>> SwapFree:              0 kB
>>>> Dirty:                40 kB
>>>> Writeback:             0 kB
>>>> AnonPages:             0 kB
>>>> Mapped:                0 kB
>>>> Shmem:                 0 kB
>>>> Slab:               1292 kB
>>>> SReclaimable:         64 kB
>>>> SUnreclaim:         1228 kB
>>>> KernelStack:         108 kB
>>>> PageTables:            0 kB
>>>> NFS_Unstable:          0 kB
>>>> Bounce:                0 kB
>>>> WritebackTmp:          0 kB
>>>> CommitLimit:        6840 kB
>>>> Committed_AS:          0 kB
>>>> VmallocTotal:          0 kB
>>>> VmallocUsed:           0 kB
>>>> VmallocChunk:          0 kB
>>>>
>>>>
>>>> I don't know actually how to move, every help is accepted.
>>>>
>>>> Many thanks,
>>>> angelo
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> uClinux-dev mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>> This message was resent by [email protected]
>>>> To unsubscribe see:
>>>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>>>
>>
>

_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev