[ROOT-6654] TProofProgressDialog signal slot error Created: 05/Sep/14  Updated: 30/Sep/14  Resolved: 30/Sep/14

Status: Closed
Project: ROOT
Component/s: Cling, Core Libraries
Affects Version/s: 6.00.02
Fix Version/s: 6.04.00

Type: Bug Priority: Medium
Reporter: Jan Andre Stillings Assignee: Philippe Canal
Resolution: Fixed Votes: 0
Labels: None




Bug when running tutorial http://root.cern.ch/drupal/content/10-go-parallel

When running PROOF, an unjustified error is shown, although everything is called correctly.

Error in <TClingCallFunc::exec>: Not enough arguments provided for TProofProgressDialog (3 instead of the minimum 5)

Comment by Axel Naumann [ 05/Sep/14 ]

Cling is right; the error is likely in some signal/slot of PROOF.

Comment by Gerardo Ganis [ 23/Sep/14 ]

Sorry for the late reply.

No, Axel, this is a bug.
The problem is that TMethodArgs::GetFullTypeName() now can return, for example, 'Long64_t' which is not recognized by TPluginHandler::ExecPlugin as a possible argument in the loop at lines 298-324 .
In the specific case, 2 out of 5 arguments are ignored, causing the error.

TPluginHandler needs to be fixed: 'Long64_t' and 'ULong64_t' need to be added, what else?

Cheers, Gerri

Comment by Axel Naumann [ 26/Sep/14 ]


I propose to change TPluginManager to pose the right question to TMethdArgs - the one that returns the underlying type.

Cheers, Axel.

Comment by Gerardo Ganis [ 27/Sep/14 ]

Changing TPluginManager is not enough. There are other places where the problem happens, but I am unable to locate them exactly. Look at the below stack trace: the number of arguments is correct until frame 5, then it goes from 7 to 4 ... I suspect a very similar cause.

Cheers, Gerri

(gdb) where
#0 TClingCallFunc::exec (this=0x2f678d0, address=0x1d77660, ret=0x0)
at /home/ganis/local/root/v6-02-00-patches/core/meta/src/TClingCallFunc.cxx:1439
#1 0x00007ffff3a94e66 in TClingCallFunc::Exec (this=0x2f678d0, address=0x1d77660, interpVal=0x0)
at /home/ganis/local/root/v6-02-00-patches/core/meta/src/TClingCallFunc.cxx:2105
#2 0x00007ffff39e7903 in TCling::CallFunc_Exec (this=0x663e30, func=0x2f678d0, address=0x1d77660)
at /home/ganis/local/root/v6-02-00-patches/core/meta/src/TCling.cxx:5904
#3 0x00007ffff7988266 in TQSlot::ExecuteMethod (this=0x2f67810, object=0x1d77660, nargs=7, ap=0x7fffffffa898)
at /home/ganis/local/root/v6-02-00-patches/core/base/src/TQConnection.cxx:312
#4 0x00007ffff7987376 in TQConnection::ExecuteMethod (this=0x2f676a0, nargs=7, va=0x7fffffffa898)
at /home/ganis/local/root/v6-02-00-patches/core/base/src/TQConnection.cxx:607
#5 0x00007ffff798a54f in TQObject::EmitVA (this=0x17a9010,
signal_name=0x7fffee552208 "Progress(Long64_t,Long64_t,Long64_t,Float_t,Float_t,Float_t,Float_t)", nargs=7, ap=0x7fffffffa898)
at /home/ganis/local/root/v6-02-00-patches/core/base/src/TQObject.cxx:657
#6 0x00007ffff798a28e in TQObject::EmitVA (this=0x17a9010,
signal_name=0x7fffee552208 "Progress(Long64_t,Long64_t,Long64_t,Float_t,Float_t,Float_t,Float_t)", nargs=7)
at /home/ganis/local/root/v6-02-00-patches/core/base/src/TQObject.cxx:616
#7 0x00007fffee4c18ae in TProof::Progress (this=0x17a8fd0, total=21920, processed=0, bytesread=0, initTime=0.501999974, procTime=0, evtrti=-1,
mbrti=-1) at /home/ganis/local/root/v6-02-00-patches/proof/proof/src/TProof.cxx:9690
#8 0x00007fffee19ed7c in TProofPlayerRemote::Progress (this=0xf384d0, total=21920, processed=0, bytesread=0, initTime=0.501999974, procTime=0,
evtrti=-1, mbrti=-1) at /home/ganis/local/root/v6-02-00-patches/proof/proofplayer/src/TProofPlayer.cxx:3243
#9 0x00007fffee1b293e in TVirtualPacketizer::HandleTimer (this=0x307b000)
at /home/ganis/local/root/v6-02-00-patches/proof/proofplayer/src/TVirtualPacketizer.cxx:417
#10 0x00007ffff79c1589 in TTimer::Notify (this=0x31c2fe0) at /home/ganis/local/root/v6-02-00-patches/core/base/src/TTimer.cxx:145
#11 0x00007ffff79c1520 in TTimer::CheckTimer (this=0x31c2fe0, now=...) at /home/ganis/local/root/v6-02-00-patches/core/base/src/TTimer.cxx:131
#12 0x00007ffff7a4df32 in TUnixSystem::DispatchTimers (this=0x637600, mode=true)
at /home/ganis/local/root/v6-02-00-patches/core/unix/src/TUnixSystem.cxx:2837
#13 0x00007ffff7a491b1 in TUnixSystem::DispatchOneEvent (this=0x637600, pendingOnly=false)
at /home/ganis/local/root/v6-02-00-patches/core/unix/src/TUnixSystem.cxx:1071
#14 0x00007ffff79af923 in TSystem::InnerLoop (this=0x637600) at /home/ganis/local/root/v6-02-00-patches/core/base/src/TSystem.cxx:409
#15 0x00007fffeee4ba4e in TMonitor::Select (this=0x2307c30, timeout=1000) at /home/ganis/local/root/v6-02-00-patches/net/net/src/TMonitor.cxx:358
#16 0x00007fffee49ca6f in TProof::Collect (this=0x17a8fd0, mon=0x2307c30, timeout=-1, endtype=-1, deactonfail=false)
at /home/ganis/local/root/v6-02-00-patches/proof/proof/src/TProof.cxx:2820
--Type <return> to continue, or q <return> to quit--

Comment by Philippe Canal [ 30/Sep/14 ]

> I propose to change TPluginManager to pose the right question to TMethdArgs - the one that returns the underlying type.

No, as the Long64_t is spelling is the normalized name. However this routine and the one in the TQSlot both should be using the numerical EDataType rather than the name as this would be much faster and more stable ... and on second thought both implementation are dangerous as they rely on the called function to describe the given argument (which would only be the case if the user has been very careful) ... I am working on a proper solution.


Comment by Philippe Canal [ 30/Sep/14 ]


This problem has been fixed in the master and the v6.02/00 patch branch.


Generated at Mon Feb 24 17:14:08 CET 2020 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.