Hi Valeri,
The problem is in the rootcint code itself. Thank for remind me about
G__tmpnam. rootcint needs to do something similar.
Cheers,
Philippe
-----Original Message-----
From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Valeri Fine
Sent: Monday, July 28, 2003 11:20 AM
To: 'Philippe Canal'; 'Pere Mato Vila'; 'Roottalk'
Subject: RE: [ROOT] rootcint crashes with access violation on Windows
Hello Philippe,
You should look up the CINT code( it is not ROOT ):
By the way I did not find any apparent problem here.
The only source of the confusion can be "G__tmpdir"
with no "drive" letter.
char* G__tmpnam(name)
char *name;
{
#if defined(G__TMPFILE)
const char *appendix="_cint";
static char tempname[G__MAXFILENAME];
char *tmp;
if('\0'==G__tmpdir[0]) {
if((tmp=getenv("CINTTMPDIR"))) strcpy(G__tmpdir,tmp);
else if((tmp=getenv("TEMP"))) strcpy(G__tmpdir,tmp);
else if((tmp=getenv("TMP"))) strcpy(G__tmpdir,tmp);
else strcpy(G__tmpdir,".");
}
if(name) {
strcpy(name,(tmp=tempnam(G__tmpdir,"")));
free((void*)tmp);
if(strlen(name)<L_tmpnam-6) strcat(name,appendix);
return(name);
}
else {
strcpy(tempname,(tmp=tempnam(G__tmpdir,"")));
free((void*)tmp);
if(strlen(tempname)<L_tmpnam-6) strcat(tempname,appendix);
return(tempname);
}
#elif defined(__CINT__)
const char *appendix="_cint";
tmpnam(name);
if(strlen(name)<G__MAXFILENAME-6) strcat(name,appendix);
return(name);
#elif /*defined(G__NEVER) && */
((__GNUC__>=3)||(__GNUC__>=2)&&(__GNUC_MINOR__>=96))&&(defined(__linux)|
|defined(__linux__))
/* After all, mkstemp creates more problem than a solution. */
const char *appendix="_cint";
strcpy(name,"/tmp/XXXXXX");
close(mkstemp(name));/*mkstemp not only generate file name but also
opens the file*/
remove(name); /* mkstemp creates this file anyway. Delete it.
questionable */
if(strlen(name)<G__MAXFILENAME-6) strcat(name,appendix);
return(name);
#else
const char *appendix="_cint";
tmpnam(name);
if(strlen(name)<G__MAXFILENAME-6) strcat(name,appendix);
return(name);
#endif
}
> -----Original Message-----
> From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]
> On Behalf Of Philippe Canal
> Sent: Monday, July 28, 2003 11:52 AM
> To: Pere Mato Vila; Roottalk
> Subject: RE: [ROOT] rootcint crashes with access violation on Windows
>
> > Would it be better to use %TEMP% or %TMP% instead
> > of the current drive letter for creating temporary files?
>
> It would. tmpnam is suppose to (I thought) to take care of that
details
> (but obviously does not :(). We will have to fix it.
>
> Cheers,
> Philippe
>
> -----Original Message-----
> From: Pere Mato Vila [mailto:Pere.Mato@cern.ch]
> Sent: Monday, July 28, 2003 10:15 AM
> To: Philippe Canal; Roottalk
> Subject: RE: [ROOT] rootcint crashes with access violation on Windows
>
>
> Thanks Philippe.
> I think I understand. I have write access to H:\ and not to E:\ in
my
> case.
> Nevertheless this is a problem for us when we build the releases in
the
> release area in AFS. Would it be better to use %TEMP% or %TMP% instead
> of the current drive letter for creating temporary files?
>
>
> > -----Original Message-----
> > From: Philippe Canal [mailto:pcanal@fnal.gov]
> > Sent: 28 July 2003 17:04
> > To: Pere Mato Vila; Roottalk
> > Subject: RE: [ROOT] rootcint crashes with access violation on
Windows
> >
> >
> > Hi Pere,
> >
> > What happens is that tmpnam is used to generate a temporary
> > file name. For some reasons and windows it return
> > \something. which means that it is in the root directory of
> > the current drive. It also happens that you do not have write
> > access to this root directory.
> >
> > Cheers,
> > Philippe.
> >
> > -----Original Message-----
> > From: owner-roottalk@pcroot.cern.ch
> > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Pere Mato Vila
> > Sent: Monday, July 28, 2003 9:28 AM
> > To: Roottalk
> > Subject: [ROOT] rootcint crashes with access violation on Windows
> >
> >
> > Dear rooters,
> >
> > I have had crashes of rootcint time to time but today I was
> > able to reproduce it just by changing the current directory.
> > I am using version v3.05.06 on windows.
> >
> > E:\cern.ch\user\m\mato\w0\GAUDI_v12r1\GaudiRootDb\v9r2\dict>
> > rootcint -f ..\dict\TBlobDict.cpp -c .. \src\TBlob.h
..\src\LinkDef.h
> > Error: rootcint: failed to open \s1gc. in main
> > And it pops-up a window saying: The instruction
> > at"0x7c014432" referenced memory at "0x0000000C". The memory
> > could not be "read"
> >
> > If I change my current directory using another drive letter
> > but pointing to the exact same place in the remote file
> > system (AFS) the command works and produces the required files.
> >
> > H:\w0\GAUDI_v12r1\GaudiRootDb\v9r2\cmt> rootcint -f
> > ..\dict\TBlobDict.cpp -c ..\src\TBlob.h ..\src\L inkDef.h
> >
> > The failing execution produces the good TBlobDict.h but the
> > TBlobDict.cpp contains only the CINT part and not the ROOT part.
> >
> > The only difference between the two executions is the
> > length of the current directory path as far I can see.
> >
> >
> > ------------------------------------------------------------
> > Pere Mato CERN, EP Division, CH 1211 Geneva 23, Switzerland
> > e-mail: Pere.Mato@cern.ch tel: +41 22 76 78696
> > fax: +41 22 76 79425 gsm: +41 79 20 10855
> >
> >
> >
> >
> > #################################################################
> > #################################################################
> > #################################################################
> > #####
> > #####
> > #####
> > #################################################################
> > #################################################################
> > #################################################################
> >
#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:14 MET