Re: g++, strange behavior issues
Angelo Dureghello <[email protected]>
| Newsgroups | gmane.linux.uclinux.devel |
|---|---|
| Message-ID | <[email protected]> |
Dear Brian and all,
thanks for your help,
below the output of "size" on 3 objects of my cpp app,
seems correct since i only have a global object for logging purpose
inside main.o.
#[ obj ] [ 18:26:43 ]
#size main.o
text data bss dec hex filename
13483 8 70 13561 34f9 main.o
#[ obj ] [ 18:26:46 ]
#size base64.o
text data bss dec hex filename
812 0 0 812 32c base64.o
#[ obj ] [ 18:26:58 ]
#size sha256.o
text data bss dec hex filename
2190 0 0 2190 88e sha256.o
I tried as you asked to keep "top" open launching the app,
it also paralize, without any update, as below.
Mem: 7772K used, 5788K free, 0K shrd, 28K buff, 728K cached
CPU: 0% usr 1% sys 0% nice 97% idle 0% io 0% irq 0% softirq
Load average: 0.00 0.00 0.00
PID PPID USER STAT VSZ %MEM %CPU COMMAND
64 62 root R 287 2% 3% top
48 1 root S 292 2% 0% -/bin/sh
45 1 root S 288 2% 0% telnetd -l /bin/sh
62 45 root S 286 2% 0% /bin/sh
1 0 root S 285 2% 0% init
47 1 root S 285 2% 0% inetd
43 1 root S 285 2% 0% ?ttpd -h /home/httpd
50 47 root S 117 1% 0% -l
51 47 root S 117 1% 0% -l
57 2 root SW 0 0% 0% [flush-1:0]
13 2 root SW 0 0% 0% [kworker/0:1]
2 0 root SW 0 0% 0% [kthreadd]
3 2 root SW 0 0% 0% [ksoftirqd/0]
12 2 root SW 0 0% 0% [mtdblock0]
5 2 root SW 0 0% 0% [kworker/u:0]
16 2 root SW 0 0% 0% [mtdblock3]
17 2 root SW< 0 0% 0% [kpsmoused]
6 2 root SW< 0 0% 0% [khelper]
7 2 root SW 0 0% 0% [sync_supers]
8 2 root SW 0 0% 0% [bdi-default]
Best regards
Angelo
On 27/01/2014 18:13, Unix Savvy Brian wrote:
> /Angelo --/
> Run *size* on your executable to see how much BSS storage is
> required. From my G++ 2.7.3 days, global C++ objects were actually in
> the data segment, even if no initialization was done....
> Also, can you get a second console connected, maybe via telnet? If
> you run *vmstat* ( or dear, that's UNIX not Linux, sorry I don't know
> the equiv ) and have it refresh often. Or put "cat /proc/meminfo" in
> a loop of every 3 seconds or so and see how your physical memory is
> changing. Also *top* provides similar info.
> just some ideas. I'm a VM linux person, not ucLinux.
> take care,
> *brianW
>
>
> On Mon, Jan 27, 2014 at 9:06 AM, Angelo Dureghello <[email protected]
> <mailto:[email protected]>> wrote:
>
> 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 <tel: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 <tel: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]
>>>>> <mailto:[email protected]>
>>>>> To unsubscribe see:
>>>>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>>>>
>>>
>>
>
>
> _______________________________________________
> uClinux-dev mailing list
> [email protected] <mailto:[email protected]>
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by [email protected]
> <mailto:[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