#1267 closed defect (fixed)

bdbuf_swapout_task's stdout FILE struct corrupted.

Reported by: Chris Johns Owned by: Chris Johns
Priority: normal Milestone: 4.9
Component: lib/block Version: 4.8
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

The stdout FILE structure as referenced by the _impure_ptr->_stdout is written over. The bug can be reproduced with the RAM disk and RTEMS shell. I am using the mfc5235 BSP with rtems-4.9 and download using BDM and GDB.

Create a simple application that registers the RAM disk driver, format the ramdisk to the MS-DOS file system, then mount it. Start the RTEMS shell.

The RAM disk is '/dev/ramdisk0' and the MS-DOS formatted file system is mounted to '/mnt/ramdisk'.

Run the test program under a debugger and set a break point at:

cpukit/libblock/src/ramdisk.c:124

Locate the address of the '_p' value in stdout's FILE struct by running the program and when the program breaks in the bdbuf_swapout_task's context at the above line in the ram disk driver obtain the address with:

(gdb) p &_impure_ptr->_stdout->_p

Monitor this value. Every time the program breaks just continue. The bdbuf_swapout_task context can be seen using the back trace command in gdb.

At the shell prompt enter:

RTEMS SHELL (Ver.1.0-FRC):. Dec 3 2007. 'help' to list commands.
/ $ cd mnt/ramdisk
mnt/ramdisk $ mkdir x
mnt/ramdisk $ ls
d--------- 0 root root 512 Jan 01 00:01 X/
1 files 512 bytes occupied
mnt/ramdisk $ cd x
mnt/ramdisk/X $ mkdir y

The application will not break on the ls or the 'cd x' but when it breaks on for the 'mkdir y' the '_p' pointer will be corrupt.

Change History (3)

comment:1 Changed on Dec 9, 2007 at 11:08:20 AM by Chris Johns

Owner: changed from Joel Sherrill to Chris Johns

comment:2 Changed on Dec 9, 2007 at 8:09:16 PM by Chris Johns

Resolution: fixed
Status: newclosed

The bug is a stack size value for the shell. On the coldfire a stack of 4096 was not enough. The shell has local data in the main look then the main_ls has much more local data. This added to the rather deep paths into the file system caused the problem.

The main fix is to review the shell and to see if some of this data can be turned into heap allocations.

comment:3 Changed on Oct 10, 2017 at 6:49:19 AM by Sebastian Huber

Component: fslib/block
Note: See TracTickets for help on using tickets.