William: Shared memory is notoriously hard, and as has been pointed out, it really sounds like a synchronization issue that you are facing. Which leads to a couple of design questions:
#1 Could what you are doing be accomplished with a POSIX threads system instead of processes? This would mean you would not need to copy the data over, just simply pass pointers from one thread to another in a producer-consumer model. #2 If you can not accomplish your solution via threads, how big is the data that you are sending and how often is it being sent? Maybe a pipe might be a better solution, as pipes intrinsically have their own synchronization built in. Walt On Sunday, August 23, 2015 at 12:31:43 AM UTC-5, William Hermans wrote: > So I have a problem with some code I've been working on for the last few > months. The code, which is compiled into two separate processes suddenly > stops working. No error, nothing in dmesg, nothing in any file in /var/log > period. It did however occur to me that since rsyslog is likely or possible > disabled. > > What my code does is read from the CAN peripheral. Form extended packets > out of the CAN frames( NMEA 2000 fastpackets ), and then writes the data > into a POSIX shared memory file ( /dev/shm/file ). The second process > simply reads from the file, and shuffles the data out over a websocket in > json / human readable form. The data on the webside of things is tested > accurate, although I do occasionally get a malformed json object warning > from firefox firebug. > > The kernel I'm currently using is 4.2.0-rc4-bone2, which seems to have no > noticeable problems. > > Anyway, I'm relatively new to Linux development, and was wondering if > anyone might be able to offer some advice as to how I can track this down. > It did occur to me that I could attempt to trap process signals, and see if > anything interesting comes of that. Short of this however, do I have any > other options ? Since my code runs for days before the processes stopping > - I'm pretty sure the traditional gdb, strace / ltrace options would be > ineffective. But maybe I'm wrong ? > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
