Sorry. False alarm.
That the va_start is called on the ap argument before this function is
called.
:-{
Ken
On 4/28/2012 6:09 PM, Jan de Kruyf wrote:
> thanks, Ken
>
> I am not such a C light to spot these things instantly.
> there are probably also some mutex problems in the combination of this with
> the rt-preempt patch.
>
> (by the way this is the UNPATCHED patch, if you see what I mean)
>
> And now it is bedtime for little children.
>
> Cheers all of you,
>
> j.
>
>
> On Sat, Apr 28, 2012 at 11:59 PM, Kenneth Lerman
> <kenneth.ler...@se-ltd.com>wrote:
>
>>
>> I started looking at funnydiff.txt and found something funny with it:
>>
>>
>>
>> The man page for stdarg (man stdarg) says (in part):
>> =============
>> va_start
>> The va_start() macro initializes ap for subsequent use by
>> va_arg() and
>> va_end(), and must be called first.
>> =============
>>
>> The following code uses the va_arg macro without first calling
>> va_start(). I don't know if that is a problem, but it is not proper
>> usage. I'm reasonably certain that it will fail on some architectures
>> with some compilers.
>>
>> Regards,
>>
>> Ken
>>
>>
>> ===========
>> +
>> +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));
>> + }
>> ==========
>>
>>
>> On 4/28/2012 5:34 PM, Jan de Kruyf wrote:
>>> Hard-working priests of the god IBM,
>>>
>>> Here is my news:
>>> I had a very hard look at the diff between the 2 commits that John so
>>> diligently found by bisecting
>>>
>>> the non-working one has basically only one addition:
>>> Jeff Eppler did this (the commit message):
>>> ----------------------------
>>> defer formatting of realtime motion messages to userspace
>>>
>>> this enables userspace to provide translations of messages printed
>> by
>>> motion, and in the future will allow floating-point values to be
>>> included in these messages.
>>> ----------------------------
>>>
>>> and in the process he made a shared memory area to catch the messages
>> from
>>> realtime, so you can read them from the user interface.
>>>
>>> So I have the itch that we are not going to find the issue by gdb etc.
>> but
>>> only by getting learned on the issue of
>>> 1. rtai interfaces
>>> 2. rt_preempt interfaces
>>> and how to go from the one to the other.
>>>
>>> I can see where John fixed the original patch to accommodate the changes
>> by
>>> Jeff, but I have not been able to identify the trouble spot / area /
>>> thinking. Mainly because my dull brain.
>>>
>>> So unless you guys have a good reason to convince me otherwise I will
>>> continue on this road of figuring out how the changing over process aught
>>> to work.
>>>
>>> I have added the diff for the interested parties.
>>>
>>>
>>> j.
>>>
>>>
>>>
>>>
>>> On Sat, Apr 28, 2012 at 10:45 PM, Charles Steinkuehler<
>>> char...@steinkuehler.net> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 4/28/2012 1:53 PM, John Morris wrote:
>>>> <snip>
>>>>> From the debugging side, neither of my tacks have gotten very far.
>>>>> I've never done anything terribly difficult with C, gdb or
>>>>> assembly before, so I've been reading docs at every step.
>>>> I'm in the same boat, I typically don't code on linux and dubug with
>>>> gdb. Normally, I'm writing VHDL (for Altera FPGAs) and debugging via
>>>> a few blinking LEDs (and by staring at the code for a long time! :).
>>>>
>>>>> The two tacks:
>>>>>
>>>>> - Use the debugger to understand why test_and_set_bit returns 0. I
>>>>> don't know what the 'tsbbl' instruction is, and haven't figured
>>>>> out how to examine memory yet.
>>>>>
>>>>> - Find some way to log function calls and argument values as the
>>>>> execution progresses. I hope to (dis)confirm that the pre-problem
>>>>> and problem versions are taking the same path up to the point
>>>>> where the problem version starts spinning. Stepping through with
>>>>> gdb is, of course, too painful. I read that valgrind might be
>>>>> able to help with this, but it doesn't seem to be a common usage.
>>>>> Charles, have you heard of using valgrind for that purpose?
>>>>>
>>>> I wasn't able to get anywhere easily with gdb, so I switched to the
>>>> GUI front-end program nemiver. It's been pretty easy to use so-far,
>>>> but I'm sure I'm missing out on some of what gdb is capable of. It is
>>>> reasonably easy to monitor memory and the call stack (at least most of
>>>> the time...I've had times where the call stack appears empty even
>>>> though there should be something there).
>>>>
>>>> As for valgrind, the on-line manual (not the man page) indicates a few
>>>> tests geared at multi-threaded code to find potential race conditions
>>>> and deadlocks. I haven't tried running any of these yet, as it
>>>> appears to assume you are using the available library mutex functions
>>>> while the linuxcnc code in question is running with custom locking
>>>> functions (which you can 'teach' valgrind about, but that is beyond my
>>>> current skill level).
>>>>
>>>> Also, I doubt there is a serious problem with the locking code, as it
>>>> is the same code that is used successfully without the linux-rtapi
>>>> patch. Instead, it seems like there is some form of memory corruption
>>>> happening, which is why I pulled out valgrind to begin with (or at
>>>> least that's what googling "crash in malloc" leads me to believe). I
>>>> suspect the change in how message strings are being handled has caused
>>>> some portion of memory to get corrupted or overwritten, but I still
>>>> don't understand the code well enough to start figuring out exactly
>>>> what's going wrong. I think I need to step back and start looking at
>>>> the program flow instead of the diffs between versions, and see when
>>>> anything related to messaging might be running and causing a problem.
>>>>
>>>> - --
>>>> Charles Steinkuehler
>>>> char...@steinkuehler.net
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.11 (MingW32)
>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>>
>>>> iEYEARECAAYFAk+cVtAACgkQLywbqEHdNFxhbwCgpVT0jUjE0Ze5wum2Tr88gMI/
>>>> 6KYAn04mouf8z4tiJtwTWdRLdp8s89js
>>>> =EJZ0
>>>> -----END PGP SIGNATURE-----
>>>>
>>>>
>>>>
>> ------------------------------------------------------------------------------
>>>> 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
>>
>> ------------------------------------------------------------------------------
>> 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
------------------------------------------------------------------------------
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
