On 08/23/2015 01:37 AM, William Hermans wrote:
Oh, and right my bad. I've run valgrind -> no problems. But both
processes stop as far as I can tell simultaneously. I've never
actually seen them stop, only the aftermath. Also, memory usage never
seems to go above ~60M total - system wide. This has me stumped . . .
On Sat, Aug 22, 2015 at 10:31 PM, William Hermans <[email protected]
<mailto:[email protected]>> 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 ?
--
William,
I'm certainly not a developer... Why do you question rsyslog? From your
explanation above I don't see the connection.
Perhaps something with the shared memory due to the fact that both
programs are failing. Really don't have a clue how to debug that one as
I've only used it as a user with ntpd and gpsd.
Using strace did come to mind, the resultant file would likely be huge
if you saved it. Trapping the exit signals might yield some clue as to
where to look.
Good luck!
Mike
--
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.
