Bug in getcwd() also in 4.11 kernel

Fri Oct 17 09:10:52 UTC 2014

I filed bug 2190:
https://www.rtems.org/bugzilla/show_bug.cgi?id=2190

a test case is attached. Due to the automatic fatfs image build procedure the Makfile process is a bit different to standard Makefile approaches.
If there are questions (or improvements to achieve the same thing) please contact me directly per email.

-----Original Message-----
From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] 
Sent: Mittwoch, 15. Oktober 2014 02:21
To: Chris Johns; Hoefle Marco; Rohner Thomas; rtems-users at rtems.org
Subject: Re: Bug in getcwd() also in 4.11 kernel

This looks like the same basic application setup and, if so, the stack size for the shell task was minimum. Almost certainly Yoo small.

On October 14, 2014 7:16:59 PM CDT, Chris Johns <chrisj at rtems.org> wrote:
>On 15/10/2014 3:09 am, Hoefle Marco wrote:
>> Hello,
>>
>> getcwd() seems also buggy on an external  FAT12 image. On 4.11 there
>is
>> no crash but this behavior:
>>
>
>Why FAT12 ?
>
>Does FAT32 work ?
>
>> RAM disks registered
>>
>> disk addr 1: 0x400c6fa0, size: 1000000
>>
>> disk addr 2: 0x40074060, size: 262144
>>
>> format /dev/rda done.
>>
>> mount return: 0
>>
>> mount return: 0
>>
>>                 Starting 1 threads...
>>
>> started thread 0: id: 0x0b010002, prio: 10
>>
>>   =========================
>>
>>   starting shell
>>
>>   =========================
>>
>> RTEMS SHELL (Ver.1.0-FRC):/dev/console. Oct 14 2014. 'help' to list
>> commands.
>>
>> [/] #
>>
>> [/] #
>>
>> [/] #
>>
>> [/] # pwd
>>
>> /
>>
>> [/] # ls
>>
>> dev   mram  sdram
>>
>> [/] # cdhello dude, this is tick nr: 0
>>
>> [/] # cd mram
>>
>> hello dude, this is tick nr: 1
>>
>> [/mram] # cd template
>>
>> [/mram/template] # pwd
>>
>> /mram/template
>>
>> [/mram/template] # ls
>>
>> logs  param
>>
>> [/mram/template] #
>>
>> [/mram/template] # cd logs
>>
>> hello dude, this is tick nr: 0
>>
>> RAM disks registered
>>
>> disk addr 1: 0x400c6fa0, size: 1000000
>>
>> disk addr 2: 0x40074060, size: 262144
>>
>> format /dev/rda done.
>>
>> mount return: 0
>>
>> mount return: 0
>>
>>                 Starting 1 threads...
>>
>> started thread 0: id: 0x0b010002, prio: 10
>>
>>   =========================
>>
>>   starting shell
>>
>>   =========================
>>
>> RTEMS SHELL (Ver.1.0-FRC):/dev/console. Oct 14 2014. 'help' to list
>> commands.
>>
>> [/] #
>>
>> [/] #
>>
>> [/] #
>>
>> [/] # pwd
>>
>> /
>>
>> [/] # ls
>>
>> dev   mram  sdram
>>
>>   [/] # cd mram
>>
>> [/mram] # cd template
>>
>> [/mram/template] # pwd
>>
>> /mram/template
>>
>> [/mram/template] # ls
>>
>> logs  param
>>
>> [/mram/template] #
>>
>> [/mram/template] # cd logs
>>
>> [?] # pwd
>>
>> ï¿½
>>
>> I'll be happy to forward the test case to an rtems developer.
>>
>
>Please create a bug report for this and attach anything you think is 
>important. The easier it is to reproduce the more chance someone will 
>look into it.
>
>Thanks
>Chris
>
>> This behavior occurs only when mounting an external fat12 image
>> generated this way:
>>
>> NAME = libfatfsimg
>>
>> BUILDDIR = build
>>
>> all: $(NAME).a
>>
>> .PHONY: $(NAME).a
>>
>> $(NAME).o:
>>
>>        @echo [GEN FATFS] $@
>>
>>        @dd if=/dev/zero of=$(NAME) bs=256 count=1024 > /dev/null
>>
>>        /sbin/mkfs.vfat -F 12 -S 512 -s 1 -r 512 -f 1 -v $(NAME)
>>
>>        mcopy -b/ -i $(NAME) content/* ::/
>>
>>        @xxd -i $(NAME) > $(NAME).c
>>
>>        @echo [CC]  $@
>>
>>        @$(CC) -c $(CFLAGS) -o $@ $(NAME).c
>>
>> $(NAME).a: $(NAME).o
>>
>> @$(AR) rcs $@ $^
>>
>> The object file is then linked against the rtems test application.
>>
>> Marco
>>
>>
>------------------------------------------------------------------------
>>
>> *From:*users [mailto:users-bounces at rtems.org] *On Behalf Of *Rohner
>Thomas
>> *Sent:* Donnerstag, 2. Oktober 2014 12:11
>> *To:* Joel Sherrill; rtems-users at rtems.org
>> *Subject:* RE: Bug in getcwd()
>>
>> Hello,
>>
>>>  We have a system with the following configuration.
>>
>>>
>>
>>> Platform:
>>
>>>
>>
>>> ·Chip GR712RC
>>
>>>
>>
>>>  ·Board: GR712 Development Board
>>
>>>
>>
>>>  ·Compiler RTEMS RCC (according to your websites version)
>>
>>>
>>
>>>  ·RTOS: RTEMS
>>
>>>
>>
>>>  ·Library: GR-RTEMS-DRIVER Version 1.2.1.0
>>
>>>
>>
>> I'm using FAT as filesystem. We have same phenomenon for FAT12 or
>FAT16!
>>
>> Freundliche Grüsse / Kind regards,
>>
>> 	
>>
>> image001
>>
>> *Thomas Rohner*
>>
>> Entwicklungsingenieur Software
>>
>> nanoTRONIC GmbH
>>
>> Werkstrasse 27, CH - 3250 Lyss
>>
>> 	
>>
>> T: +41 32 384 69 30, F: +41 32 384 69 31
>>
>> www.nanotronic.ch <http://www.nanotronic.ch/> |
>> thomas.rohner at nanotronic.ch <mailto:thomas.rohner at nanotronic.ch>
>>
>> *From:*Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
>> *Sent:* Mittwoch, 1. Oktober 2014 20:11
>> *To:* Rohner Thomas; rtems-users at rtems.org
>> *Subject:* Re: Bug in getcwd()
>>
>> On 10/1/2014 9:26 AM, Rohner Thomas wrote:
>>
>>     Hello,
>>
>>     maybe I found a bug in getcwd().
>>
>>     We're using RTEMS 4.0 with Gaisler-Aeroflex....
>>
>>     With our libraries I get an erroneous string when directory-depth
>is
>>     about 4 folders from root!
>>
>>     When I use this string to read directory it crahes!
>>
>>     Is there a limitation of string-length?
>>
>>     I get the same results for
>>
>>     Char buffer[200];
>>
>>     getcwd(buffer,sizeof(buffer));
>>
>>     or
>>
>>     char* ret = getcwd(NULL,0);
>>
>> Is this with the IMFS? What BSP?
>>
>> Can you put together a full test example so we can
>> see what is really happening?
>>
>> There is a POSIX constant for PATH_MAX as I recall but
>> it is quite large.
>>
>> Freundliche Grüsse / Kind regards,
>>
>> 	
>>
>> image001
>>
>> *Thomas Rohner*
>>
>> Entwicklungsingenieur Software
>>
>> nanoTRONIC GmbH
>>
>> Werkstrasse 27, CH - 3250 Lyss
>>
>> 	
>>
>> T: +41 32 384 69 30, F: +41 32 384 69 31
>>
>> www.nanotronic.ch <http://www.nanotronic.ch/> |
>> thomas.rohner at nanotronic.ch <mailto:thomas.rohner at nanotronic.ch>
>>
>> --
>>
>> Joel Sherrill, Ph.D.             Director of Research & Development
>>
>> joel.sherrill at OARcorp.com  <mailto:joel.sherrill at OARcorp.com>        
>On-Line Applications Research
>>
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>
>> Support Available                (256) 722-9985
>>
>>
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>