Random reboot while tcp-ip file transmission

[Altera_Forum]

Hello , 

 In my application, I have to transmit a file threw tcp-ip between another embedded linux and my uClinux. Quite offently, uClinux reboots automatically. When I do it again, it doesn't behave the same.  I wonder if it's a problem of design or it's because my memory use is Rash. (I allocate a partition of 4Mb threw mmap in which I gradually put the file).  So, I have 3 questions : -> Has somebody already have such a problem ? -> What could I do to investigate or solve my problem ? -> Is the memory reinitialized after a reboot ?  Every help would be really appreciated,  Cedric, alone in front of his capricious card.

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  -> Has somebody already have such a problem ?[/b]  --- Quote End ---    No, actually not. I&#39;m doing a lot of network stuff. Linux is rock stable.  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  What could I do to investigate or solve my problem[/b]  --- Quote End ---    - maybe you can check your code with a source code checker? Is it possible that you fool around with some memory ptr?   - check your design or your memory. - does uClinux also reboot when your application is not running?  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  Is the memory reinitialized after a reboot ?[/b]  --- Quote End ---    i don&#39;t know.

[Altera_Forum]

--- Quote Start ---  originally posted by helmchen@Feb 26 2007, 07:47 PM <div class='quotetop'>quote   --- quote end ---    --- quote start ---  - maybe you can check your code with a source code checker? is it possible that you fool around with some memory ptr?  --- Quote End ---   Well it&#39;s always possible. I used this application under windows XP thousands of times but there may be errors in the linux specific library.  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  - does uClinux also reboot when your application is not running?[/b]  --- Quote End ---   No, nether. But, sometimes, the first run of the application is ok. I run the application again and I have the message "BINFMT_FLAT : reloc outside program 0xdf850000 (0x0x5d1ac/0x40140), killing my_app. SIGSEV  In other cases, when the tcp/ip connection is established, my telnet is automatically closed and the terminal doesn&#39;t answer anymore.  [/b]  --- Quote End ---  

[Altera_Forum]

i would like to add some details : 

 -> my app is a mix of c++ and c -> My app is located on a nfs drive. -> In the beginning, I allocate 4Mb with mmap but I never free it because I stop my app with kill -9. I don&#39;t think it can be the reason of my problem ; can it ? -> I have 32 Mb of memory and my app takes 4973 (says ps)  It seems that when I change the romfs and when I upload it to the board, my app always behave ok.  When I put on my board after a few hours it has been off, my app seems to beahave also ok.  If it&#39;s memory problem, what can I do to detect it ? what tool can i use ?  thanks,  Cedric

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  If it&#39;s memory problem, what can I do to detect it ? what tool can i use ?[/b]  --- Quote End ---    you can a create a program, that writes a pattern into memory , then verify by reading the memory again. You can use the example project "Memory Test" from altera.  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  My app is located on a nfs drive.[/b]  --- Quote End ---   I use nfs, too, without any problems, but i use the uclinux from nioswiki with initramfs.  maybe it is nfs issue. There is a nfs guide on the www.nioswiki.jot.com. you may also try to transfer your program via ftp and run it.  another thing in general if you want to allocate big buffers (>1MB) of memory, you must enable this kernel configuration in order to do this.

[Altera_Forum]

--- Quote Start ---  originally posted by helmchen@Feb 27 2007, 03:52 PM <div class='quotetop'>quote   --- quote end ---    --- quote start ---  you can a create a program, that writes a pattern into memory , then verify by reading the memory again. you can use the example project "memory test" from altera.  --- Quote End ---   I tried this. I made a program that allocates 4Mb of memory with the same functions than in the other program ; I wrote a pattern and read it until I stop it. I&#39;ve detected no problem, even when the other one is working  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  maybe it is nfs issue. There is a nfs guide on the www.nioswiki.jot.com. you may also try to transfer your program via ftp and run it.[/b]  --- Quote End ---   I&#39;ve integrated my prog to the file system, and I always have the same problems. So, it&#39;s not due to nfs  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  another thing in general if you want to allocate big buffers (>1MB) of memory, you must enable this  kernel configuration in order to do this.[/b]  --- Quote End ---    This option was already enabled because i&#39;ve had the problem.  Another strange thing : I&#39;ve discovered today that the guy who works with me and who is responsible for the kernel hasn&#39;t patch the kernel source files as it is required in "Davicom DM9000 linux note". The Davicom is the ethernet device and this patch allows this device to detect the cpu clock frequency. When I discovered it I thought I had found MY solution .... but well, nothing changed after the kernel recompilation and upload.  <div align='right'><{post_snapback}> (index.php?act=findpost&pid=21905)</div> [/b]  --- Quote End ---    I&#39; ve also noticed that I had only "4" in /proc/sys/net/tcp_rmem whereas the linux doc says that it should be a vector of 3 values. Can it have an impact ? I transfer to the uClinux a file through tcp-ip in packets of 8k.  Well, if someone has an idea, even a crazy one, try it please.  Cedric

[Altera_Forum]

Hello everybody ! 

 Well, I think I found the roots of my problem. It was due to the stack size of a multithread application. The stack size that you indicates at compile time is the stack size of the main thread. You have to indicate the stack size of the other threads.  Well, it&#39;s good too know !  Bye