RE: [ROOTDEV] Bug in root/test/Event.cxx (PR#2670)

From: GENTIT Francois-Xavier DAPNIA <GENTIT_at_dapnia.cea.fr>
Date: Mon, 7 Feb 2005 10:09:38 +0100


Philippe,
Thanks a lot, I was not aware at all of this problem of /MLd versus /MD. I will include your indications in my web site

 http://www.slac.stanford.edu/~gentit/

I would be very grateful to you if you find other errors or omissions on this web page.

F.X.Gentit
DAPNIA/SPP CEA Saclay
http://gentit.home.cern.ch/gentit/  

> -----Message d'origine-----
> De : Philippe Canal [mailto:pcanal_at_fnal.gov]
> Envoyé : vendredi 4 février 2005 17:57
> À : GENTIT Francois-Xavier DAPNIA
> Cc : rootdev_at_pcroot.cern.ch
> Objet : RE: [ROOTDEV] Bug in root/test/Event.cxx (PR#2670)
>
> Hi,
>
> The problem is that on Windows, the developer has to insure that all the
> library are build against a consistent set of libraries. In particular
> ROOT is usually build with the /MD option (Multi-thread library) while you
> project build event.exe with the /MLd (Single threaded debug).
>
> In addition, neither the compiler/linker nor the run-time environment
> warns
> you of the mis-match.
>
> So in your case there is some memory that is allocated with the
> libCore.dll
> library using the new operator provided by the /MD options.
>
> In your event.exe (because SetBitNumber is inlined and can allocate
> memory)
> when the the bits needs to increase, the memory is deallocated using the
> delete operator provided by /MLd (the problem would be same with /MDd)
> which
> expect ___extra___ debug information to have been placed by new. It
> complains when it does not find it.
>
> To solve the problem link with /MD (Project Properties/C/C++/Code
> Geneerator/Runtime Library).
>
> Cheers,
> Philippe.
>

Hi,

I now see the problem. I could not see it before because you are using extra debug flags (including debugging deletes) that I did not have.

Make the modification you are proposing does not fix the underlying problem but work-around it.

The assertion complains that a delete does not match the allocation (so far I don't why but that's another storey). Your modification makes the problem vanished by not requiring the delete in the first ... However the delete is (and should) be part of normal operation.

So now I have to understand why the system thinks the deletes do not macth :(.

Cheers,
Philippe.> -----Original Message-----
> From: GENTIT Francois-Xavier DAPNIA [mailto:GENTIT_at_DAPNIA.CEA.FR]
> Sent: Friday, February 04, 2005 3:33 AM
> To: 'Philippe Canal'
> Subject: RE: [ROOTDEV] Bug in root/test/Event.cxx (PR#2670)
>
> Hi Philippe,
>
> To be extremely precise, here is the full message of Visual C++7.1, in
> debug
> mode, before break:
>
> Debug Assertion failed
> Program:D:\sv\Projetspp\FromRoot\event\Debug\event.exe
> File: dbgdel.cpp
> Line: 52
> Expression: _BLOCK_TYPE_IS_VALID(pHead->bBlockUse)
>
> The message is emitted in the method Event::Build, when reaching the
> second
> of the 3 identical lines:
>
> fTriggerBits.SetBitNumber((UInt_t)(64*gRandom->Rndm(1)));
> fTriggerBits.SetBitNumber((UInt_t)(64*gRandom->Rndm(1)));
> fTriggerBits.SetBitNumber((UInt_t)(64*gRandom->Rndm(1)));
>
> the number given in argument being 9, the dimension of fNbits being 8.
> I join the full program to this mail in case you want to check it on your
> PC.
>
> F.X.Gentit
> DAPNIA/SPP CEA Saclay
> http://gentit.home.cern.ch/gentit/
>
> > -----Message d'origine-----
> > De : Philippe Canal [mailto:pcanal_at_fnal.gov]
> > Envoyé : jeudi 3 février 2005 17:44
> > À : 'gentit'
> > Objet : RE: [ROOTDEV] Bug in root/test/Event.cxx (PR#2670)
> >
> > > Strange that you have not the same message "debug assertion failed".
> >
> > Not only strange, I claim that it can not possibly have come from the
> line
> > of code your refer to.
> >
> > > in any case, you agree that the dimension fNbits is 8 instead of 64?
> >
> > Yes I agree, but this should make absolutely no differences (beside
> > improving performance)!.
> >
> > I am pretty certain that either your are not ussing 4.03/01 or the
> problem
> > is somewhere else!
> >
> > Cheers,
> > Philippe.
> >
> > -----Original Message-----
> > From: gentit [mailto:gentit_at_hep.saclay.cea.fr]
> > Sent: Thursday, February 03, 2005 2:17 AM
> > To: Philippe Canal
> > Subject: Re: [ROOTDEV] Bug in root/test/Event.cxx (PR#2670)
> >
> > Philippe Canal wrote:
> > Hi,
> > Strange that you have not the same message "debug assertion failed". But
> > in any case, you agree that the dimension fNbits is 8 instead of 64?
> > F.X.Gentit
> > DAPNIA/Spp
> >
> > >Hi,
> > >
> > >I can not reproduce the problem (on windows XP with Visual C++ 7.1 in
> > debug
> > >mode).
> > >I can even understand the link between the problem (a debug assertion
> > >failing) and the proposed solution since I not see any such debug
> > assertion
> > >in the code of SetBitNumber. In the contrary I see in the code of
> > >SetBitNumber the handling of fNbits being of insufficient size.
> > >
> > >Philippe.
> > >
> > >-----Original Message-----
> > >From: owner-rootdev_at_pcroot.cern.ch [mailto:owner-
> rootdev_at_pcroot.cern.ch]
> > On
> > >Behalf Of gentit_at_hep.saclay.cea.fr
> > >Sent: Monday, January 31, 2005 5:45 AM
> > >To: rootdev_at_pcroot.cern.ch
> > >Cc: root-bugs_at_pcroot.cern.ch
> > >Subject: [ROOTDEV] Bug in root/test/Event.cxx (PR#2670)
> > >
> > >Full_Name: Gentit François-Xavier
> > >Version: 4.03/01
> > >Hardware: PC Dell
> > >OS: Windows XP
> > >Severity: normal
> > >Reproducable: always
> > >Submission from: (NULL) (132.166.11.150)
> > >
> > >
> > >Line:
> > >
> > >Event::Event() in root/test/Event.cxx should be
> > >
> > >Event::Event() : TObject(),fTriggerBits(64)
> > >
> > >Because of this error, program "Event" fails under Visual C++ 7.1 IN
> > DEBUG
> > >MODE,
> > >with the message: "Debug Assertion failed", at line:
> > >
> > >fTriggerBits.SetBitNumber((UInt_t)(64*gRandom->Rndm(1)));
> > >
> > >of method Event::Build()
> > >
> > >This message is emitted because fTriggerBits.fNBits is 8 and the
> argument
> > >provided is bigger than 8
> > >
> > >
> > >
> > >
> > >
> >
> >
>
Received on Mon Feb 07 2005 - 10:24:59 MET

This archive was generated by hypermail 2.2.0 : Tue Jan 02 2007 - 14:45:04 MET