From funnydiff.txt...
+int vstashf(struct dbuf_iter *o, const char *fmt, va_list ap) {
+ int modifier_l;
+
+ dbuf_put_string(o, fmt);
+
+ while((fmt = strchr(fmt, '%'))) {
+ int code = get_code(&fmt, &modifier_l);
+
+ switch(code) {
+ case '%':
+ break;
+ case 'c': case 'd': case 'i': case 'x': case 'u': case 'X':
+ if(modifier_l) {
+ case 'p':
+ dbuf_put_long(o, va_arg(ap, long));
+ } else {
+ dbuf_put_int(o, va_arg(ap, int));
+ }
+ break;
+ case 'e': case 'E': case 'f': case 'F': case 'g': case 'G':
+ dbuf_put_double(o, va_arg(ap, double));
+ break;
+ case 's':
+ dbuf_put_string(o, va_arg(ap, const char *));
+ break;
+ default:
+ return SET_ERRNO(-EINVAL);
+ break;
+ }
+ }
+ return 0;
+}
Look at the line with:" if(modifier_l) {"
This looks like a variation of Duff's Device, but it is not clear to me
what is intended and what actually happens. My guess is that case 'p'
should always be treated as a long.
I would rewrite this as:
+int vstashf(struct dbuf_iter *o, const char *fmt, va_list ap) {
+ int modifier_l;
+
+ dbuf_put_string(o, fmt);
+
+ while((fmt = strchr(fmt, '%'))) {
+ int code = get_code(&fmt, &modifier_l);
+
+ switch(code) {
+ case '%':
+ break;
+ case 'c': case 'd': case 'i': case 'x': case 'u': case 'X':
+ if(modifier_l) {
+ dbuf_put_long(o, va_arg(ap, long));
+ } else {
+ dbuf_put_int(o, va_arg(ap, int));
+ }
+ break;
+ case 'p':
+ dbuf_put_long(o, va_arg(ap, long));
+ break;
+ case 'e': case 'E': case 'f': case 'F': case 'g': case 'G':
+ dbuf_put_double(o, va_arg(ap, double));
+ break;
+ case 's':
+ dbuf_put_string(o, va_arg(ap, const char *));
+ break;
+ default:
+ return SET_ERRNO(-EINVAL);
+ break;
+ }
+ }
+ return 0;
+}
That is, make 'p' its own case with a dbuf_put_long.
Note that there is a similar issue later in funnydiff.txt in
------------------------- src/emc/motion/stashf_wrap.h
-------------------------
Hope this helps.
Ken
On 5/3/2012 7:41 PM, Charles Steinkuehler wrote:
> On 5/3/2012 5:26 PM, Charles Steinkuehler wrote:
>> If you run with electric fence, you'll get a segfault well before the
>> malloc crash, where one of the debug writes to stderr is stepping on
>> memory that it shouldn't (which is likely what is eventually causing
>> malloc to barf). Looking at what might be corrupting the stderr
>> structure is what lead me to point the finger at the rtapi_print_msg
>> from rtapi_clock_set_period.
> Just wanted to say I'm going to be going off-line for a while (until
> next Wednesday). I'll have e-mail, but no access to a development platform.
>
> I was hoping to track down the cause of this bug first, but didn't quite
> make it. I do think the call chain leading up to the function
> default_rtapi_msg_handler is the culprit, but I haven't figured out
> exactly why. What I do know is:
>
> Result of calls to default_rtapi_msg_handler
> NOTE: Using electric fence to identify memory problems!
> =============================================
> 1st call (via rtapi_clock_set_period) causes the memory region holding
> _IO_FILE * stderr to be overwritten
>
> 2nd call (via rtapi_task_new) ???
>
> 3rd call (via rtapi_reset_pagefault_count) !!-CRASH-!! ...or hit the
> "electric fence"
> =============================================
>
> Note that this is *WITHOUT* the patch I made, so the code is trying to
> write to stderr (which is apparently getting corrupted). It is easy to
> reproduce this in gdb by running rtapi_app, setting a break-point on
> default_rtapi_msg_handler, and hitting 'c' a few times. The break
> happens before the nastiness (which occurs in the vfprintf routine), so
> you can poke around memory and the call stack before firing off the
> vfprintf if you want (example gdb session attached).
>
> That's as close to a smoking gun as I've been able to uncover...
>
> ...maybe someone a bit more versed in C and passing variable length
> argument lists can spot what's going wrong. For all I know, the
> electric fence segfault above is unrelated to the 'real' crash later on
> in malloc(), and instead is some issue with the electric fence library
> and pthreads, and the overwrite of the stderr memory structure could be
> expected behavior.
>
> Anyway, thanks for all the help so far!!!
>
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
