On 5/3/2012 5:01 PM, John Morris wrote: > Hi EBo, > >> Usually when malloc wedges up like this it is caused by just a coupe of >> things 1) a double free of the same allocated block, 2) writing past the >> end of a block, or 3) freeing up memory that was allocated by one >> process but still accessing it in a different one. Anyway that is my >> personal experience. YMMV. > > I'm sure that's right. However, it requires familiarity with the code > that I don't have to find that sort of thing, so I've been trying (and > failing) to save time by using tools instead. > >> If that is the problem, good luck finding >> that. If you do I'll buy you a beer, pot of tea, or ice-cream cone (you >> name your favorite poison) > > Woo hoo! EBo's doubled the bounty! Hopefully we'll find the bug twice > as fast now. ;)
I've managed to figure out that the call to rtapi_print_msg in rtapi_clock_set_period is trashing the memory area used to define stderr, but I still don't understand why. I think I'm going to have to work out how these ellipsis things work in 'C'. I'm used to working in strongly typed languages where you don't just throw stuff on the stack and hope the code on the other end can deal with it properly. I guess it took too long to crash the machine writing assembly, so they invented C. From the history of programming languages: > http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html 1972 - Dennis Ritchie invents a powerful gun that shoots both forward and backward simultaneously. Not satisfied with the number of deaths and permanent maimings from that invention he invents C and Unix. *wanders off muttering about void pointers and stack frames* -- Charles Steinkuehler char...@steinkuehler.net ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
