On 14/3/20 9:17 am, dufa...@hda.com wrote: >> On Mar 13, 2020, at 16:49 , Chris Johns <chr...@rtems.org> wrote: >> >> On 14/3/20 6:16 am, dufa...@hda.com wrote: >>>> On Mar 13, 2020, at 08:42 , Sebastian Huber >>>> <sebastian.hu...@embedded-brains.de> wrote: >>>>> Finally, after initial successful loop-back testing, I tried to start an >>>>> RTEMS shell on one of the new ports. >>>>> >>>>> *Here I'm trying hard to avoid all-caps because this took the most time >>>>> of all (it should have been easiest), and I gave up!* >>>>> >>>>> * HOW (sorry) do you spawn a shell on a serial port? The documentation, >>>>> at >>>>> https://docs.rtems.org/branches/master/shell/configuration_and_init.html >>>>> that suggests just setting the shell device name to "/dev/console", or in >>>>> my case "/dev/ttyS9", is incorrect. The shell startup is intent on using >>>>> "stdin" and "stdout". >> >> I am guessing it is a bug. I tripped over some issues ... >> >> https://devel.rtems.org/ticket/3859 >> >>>> I don't know this off hand. >>> >>> I don't need the shell spawned on one of the added serial ports. I thought >>> it would be an easy way to test the driver, but it isn't. Obviously the >>> "telnet" daemon does some monkeying around with "stdin" and "stdout" in >>> order that it works via telnet. >> >> A serial port should work with just the paths. You should also be able to do >> the >> same method as telnet and assign open descriptors then call the shell's main >> loop. >> >>> * It would be great if it worked but I'm not going to investigate it. >> >> I wonder if the issues you see are part of what I have fixed with .. >> >> https://lists.rtems.org/pipermail/devel/2020-February/057422.html >> >> The patch has not been pushed. I have pushed the changes to the 4.11 branch >> and >> I am planing to update the master version this week. >> >> Chris > > That looks very promising. But what does this part mean? Is it that > anything that is a shell environment should have the unique magic number > derived from "rtems_build_name" that evaluates to SENV? So all shell > environments will have the magic number SENV? If I interpret that correctly > it is pretty paranoid for a structure that is passed as part of > initialization, where corruption isn't that common. > > + if (shell_env->magic != rtems_build_name('S', 'E', 'N', 'V')) { > + rtems_error(0, "invalid shell environment passed to the main loop)"); >
The patch changes the struct so it has to be initialised by one of the shall calls, either alloc me a struct, i.e. managed, or by cloning the calling threads structure into a supplied struct. If this does not happen the POSIX key destructor may follow the wrong path and corrupt the heap with invalid free calls or the memory may leak. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
