|
From: smiley g. <smi...@ya...> - 2004-07-15 07:35:22
|
Hi friends, It finally turned out that the reason was not the upgrade to update 2. Its because of an smp kernel. my application hangs when run on smp kernel 2.4.21-15.ELsmp, but not on 2.4.21-15.EL. Thanks, Madhan. --- smiley glitter <smi...@ya...> wrote: > Hi friends, > > I had my application almost up and running with > valgrind, when the admins upgraded my Linux machine > to > RedHat Linux AS 3 upgrade 2. I am facing a hang and > I > have no clue where its happening. > > The application starts numerous daemon processes and > > involves interaction among these daemon processes. I > am not able to attach a debugger to these processes > when valgrind is involved and --db-attach doesn't > work > with fork'd processes yet. > > Can somebody give me a clue about how to attach > debugger to a daemon process and get to see code in > the debugger. when i do a backtrace I only see a > list > of addresses and addr2line utility doesn't give me > anything new. > > or anybody seeing anything new with upgrade 2 ? > > or anybody knows is valgrind uses pipes internally ? > for I know that my application doesn't use pipes but > /proc/pid/fd lists a few pipes ??? > > Thanks a lot in advance, > Madhan. > > > > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - 100MB free storage! > http://promotions.yahoo.com/new_mail > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 17:20:55
|
On Thu, 15 Jul 2004, smiley glitter wrote: > It finally turned out that the reason was not the > upgrade to update 2. > > Its because of an smp kernel. > > my application hangs when run on smp kernel > 2.4.21-15.ELsmp, but not on 2.4.21-15.EL. I don't have any useful suggestions, but you might like to file a bug report so this isn't forgotten. N |
|
From: smiley g. <smi...@ya...> - 2004-07-19 14:23:56
|
I have proceeded a little more...
My application is trying to run the following code,
written as assembly in a multiprocessor environment.
This function is passed an address (data address) and
old_value and new_value. it compares is the data in
the address is equal to the old value. if true it puts
the newvalue in place and returns true. returns false
otherwise.
---------------------
.text
.align 16
.globl swapit
.type swapit,@function
swapit:
movl 4(%esp),%ecx /* ecx = data address */
movl 8(%esp),%eax /* eax = old_value */
movl 12(%esp),%edx /* edx = new_value */
lock; cmpxchgl %edx,(%ecx) /* Atomic compare
and swap */
setz %al
movzbl %al,%eax /* put ZF into %eax */
ret /* return */
.size swapit,.-swapit
----------------------
when I enable --trace-codegen=11111
then in the first stage I see the LOCK
(2) 0x8048428: movl 12(%esp,,),%edx
(2)
(2) 10: GETL %ESP, t14
(2) 11: LEA1L 12(t14), t12
(2) 12: LDL (t12), t16
(2) 13: PUTL t16, %EDX
(2) 14: INCEIPo $4
(2)
(2) 0x804842C: cmpxchgl %edx,(%ecx)
(2)
-->(2) 15: LOCKo
(2) 16: GETL %ECX, t26
(2) 17: LDL (t26), t22
(2) 18: GETL %EDX, t20
(2) 19: GETL %EAX, t18
(2) 20: MOVL t18, t24
(2) 21: SUBL t22, t24
(-wOSZACP)
(2) 22: CMOVLz t20, t22
(-rOSZACP)
(2) 23: CMOVLnz t22, t18
(-rOSZACP)
----------------------
At the last stage - instrumented code I donot see the
LOCK
(2) 12: LDL (t12), t16
(2) 13: PUTL t16, %EDX
(2) 14: INCEIPo $4
(2) 15: CCALLo 0xB72A4BB1(t4)
(2) 16: LDL (t4), t22
(2) 17: MOVL t10, t24
(2) 18: SUBL t22, t24 (-wOSZACP)
(2) 19: CMOVLz t16, t22 (-rOSZACP)
(2) 20: CMOVLnz t22, t10 (-rOSZACP)
-------------------
From the addrcheck code too I see that
switch (u_in->opcode) {
case NOP: case LOCK: case CALLM_E: case
CALLM_S:
break;
these calls are just ignored.
Can you please clarify if my above code will get
executed rightly when run in a smp kernel.
In the documentation I read that the thread model uses
only one cpu at a time. in any case there seems to be
no atomicity guaranteed in case of lock instruction.
Thanks,
Madhan
--- Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 15 Jul 2004, smiley glitter wrote:
>
> > It finally turned out that the reason was not the
> > upgrade to update 2.
> >
> > Its because of an smp kernel.
> >
> > my application hangs when run on smp kernel
> > 2.4.21-15.ELsmp, but not on 2.4.21-15.EL.
>
> I don't have any useful suggestions, but you might
> like to file a bug
> report so this isn't forgotten.
>
> N
>
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
|
|
From: Tom H. <th...@cy...> - 2004-07-19 14:32:52
|
In message <200...@we...>
smiley glitter <smi...@ya...> wrote:
> Can you please clarify if my above code will get
> executed rightly when run in a smp kernel.
It should do, yes. All LOCK prefixes will be dropped by valgrind but
as it only ever executes one thread at a time, and will never switch
threads in the middle of an instruction, it shouldn't matter.
> In the documentation I read that the thread model uses
> only one cpu at a time. in any case there seems to be
> no atomicity guaranteed in case of lock instruction.
Exactly. It only uses one CPU so locking is not relevant.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Paul P. <pa...@pa...> - 2004-07-19 15:41:27
|
>>>>> On Mon, 19 Jul 2004 15:32:41 +0100, Tom Hughes <th...@cy...> said:
> All LOCK prefixes will be dropped by valgrind [...]
AFAICT, this prevents valgrind from working correctly on applications
that are implemented as a set of cooperating processes (real
processes, not clone()s) with synchronisation/communication via
shared memory.
Perhaps that should be listed in the "2.12 Limitations" section?
Cheers,
--
Paul Pluzhnikov pa...@pa...
|
|
From: Tom H. <th...@cy...> - 2004-07-19 15:50:03
|
In message <166...@bu...>
Paul Pluzhnikov <pa...@pa...> wrote:
>>>>>> On Mon, 19 Jul 2004 15:32:41 +0100, Tom Hughes <th...@cy...> said:
>
> > All LOCK prefixes will be dropped by valgrind [...]
>
> AFAICT, this prevents valgrind from working correctly on applications
> that are implemented as a set of cooperating processes (real
> processes, not clone()s) with synchronisation/communication via
> shared memory.
If they rely on LOCK prefixes to manage access to the shared
memory then yes (although only on SMP machines, obviously).
I would have thought it was more normal to use a heavier duty
synchronisation system in such a case however - posix semaphores
or something.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: John R.
|
Tom Hughes wrote: > In message <166...@bu...> > Paul Pluzhnikov <pa...@pa...> wrote: > > >>>>>>>On Mon, 19 Jul 2004 15:32:41 +0100, Tom Hughes <th...@cy...> said: >> >> > All LOCK prefixes will be dropped by valgrind [...] >> >>AFAICT, this prevents valgrind from working correctly on applications >>that are implemented as a set of cooperating processes (real >>processes, not clone()s) with synchronisation/communication via >>shared memory. > > > If they rely on LOCK prefixes to manage access to the shared > memory then yes (although only on SMP machines, obviously). No. Even a one-CPU machine with an intelligent PCI or AGP card of almost any kind (video, ethernet, crypto, smart [multiple] serial, etc.) could rely on uninterruptible read-modify-write cycles. valgrind's dropping of LOCK will cause memcheck to be unusable for any application that talks directly to such a hardware device. This can include the usual case of X11 display. -- |