case M_FILE_OPEN:
new TGFileDialog(fClient->GetRoot(), this, kFDOpen, &fi);
if(fi.fFilename) GetTree();
break;
And when I am trying to double click a directory or just press go up one level button I get segmentation violation with following output. However, in root cession when I open TGFileDialog from File menu of TCanvas everything works fine.
*** Break *** segmentation violation
Generating stack trace…
0x02469203 in operator delete(void*) + 0x23 from /usr/lib/libstdc++.so.5
0x0246925f in operator delete + 0x1f from /usr/lib/libstdc++.so.5
0x05fe4d0e in TGFileDialog::ProcessMessage(long, long, long) + 0x1c6 from /usr/
local/root/lib/libGui.so
0x05fec962 in TGFrame::HandleClientMessage(Event_t*) + 0x36 from /usr/local/roo
t/lib/libGui.so
0x05fef55e in TGMainFrame::HandleClientMessage(Event_t*) + 0x22 from /usr/local
/root/lib/libGui.so
…
I use root 4.00/08,
libstdc++ Version : 3.2.3,
Scientific Linux,
gcc 3.2.3
You have the same problem with same version of root and same version of compiler (and linux)?
If not, can you send a running macro showing the problem?
I am using root version 5.14/00f on lxplus. I am using this function in this following code:
void Interface::OpenFile()
{
//Type for the files allowed
const char *filetypes[] = {"ROOT files", "*.root"};
//Initial directory
TString directory(".");
TGFileInfo file_info;
file_info.fFileTypes = filetypes;
file_info.fIniDir = StrDup(directory);
//Open the dialox box
new TGFileDialog(gClient->GetRoot(), this, kFDOpen, &file_info);
if(file_info.fFilename)
{
//Save the name
path_file = file_info.fFilename;
path_file_ok = true;
fTextButtonFitData->SetEnabled(true);
TFile *file = new TFile(path_file);
file->cd(path_file + ":/NTuples");
}
}
The first time I use this function, it works, the second time I have the following error:
*** Break *** segmentation violation
(no debugging symbols found)
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
Attaching to program: /proc/8377/exe, process 8377
(no debugging symbols found)...done.
(no debugging symbols found)...done.
(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 4133443264 (LWP 8377)]
0xffffe410 in __kernel_vsyscall ()
#1 0x008d7d23 in __waitpid_nocancel () from /lib/tls/libc.so.6
#2 0x008817a9 in do_system () from /lib/tls/libc.so.6
#3 0x009b198d in system () from /lib/tls/libpthread.so.0
#4 0xf7a11df5 in TUnixSystem::Exec ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#5 0xf7a122b9 in TUnixSystem::StackTrace ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#6 0xf7a10064 in TUnixSystem::DispatchSignals ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#7 0xf7a0de64 in SigHandler ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#8 0xf7a14c6c in sighandler ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#9 <signal handler called>
#10 0x008b69a3 in strlen () from /lib/tls/libc.so.6
#11 0x0088a731 in vfprintf () from /lib/tls/libc.so.6
#12 0x008a29cb in vsprintf () from /lib/tls/libc.so.6
#13 0x0088fd4b in sprintf () from /lib/tls/libc.so.6
#14 0xf60e37bf in TGFileDialog::TGFileDialog ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#15 0xf4ee42d4 in Interface::OpenFile () from /afs/cern.ch/user/p/ppernet/scratch0/GUI/src/./Interface_C.so
#16 0xf4eecf17 in G__file9OcCvL_2203_0_17 ()
from /afs/cern.ch/user/p/ppernet/scratch0/GUI/src/./Interface_C.so
#17 0xf725330d in Cint::G__CallFunc::Execute ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCint.so
#18 0xf78e8336 in TQConnection::ExecuteMethod ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#19 0xf78ebf87 in TQObject::Emit ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#20 0xf60b7102 in TGButton::Clicked ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#21 0xf60b071e in TGButton::EmitSignals ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#22 0xf60b043b in TGButton::SetState ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#23 0xf60b05fa in TGButton::HandleButton ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#24 0xf60f0a9c in TGFrame::HandleEvent ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#25 0xf60c4bf6 in TGClient::HandleEvent ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#26 0xf60c481d in TGClient::ProcessOneEvent ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#27 0xf60c4934 in TGClient::HandleInput ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#28 0xf60c2bf4 in TGInputHandler::Notify ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libGui.so
#29 0xf7a0f109 in TUnixSystem::DispatchOneEvent ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#30 0xf7911c9c in TSystem::InnerLoop ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#31 0xf7911c35 in TSystem::Run ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#32 0xf7886119 in TApplication::Run ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libCore.so
#33 0xf671f9c0 in TRint::Run ()
from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00f-CMS3q//lib/libRint.so
#34 0x08048d81 in main ()
Root >
OK, I cannot reproduce the problem with /afs/cern.ch/sw/lcg/external/root/5.14.00f/slc4_ia32_gcc34…
Could you try to run $ROOTSYS/tutorials/gui/guitest.C and open the TGFileDialog several times, to see if it crashes the same way?
Seems to be a problem on your side then… You should debug your session and set a breakpoint at this location to see what’s happening…
I cannot help much there.
Ok, in fact it is really strange, because if there is nothing between my new TFile and my delete it works, but if there is a line of code, there is an error…
I come back to this message 6 months after. I am now using Root 5.22 and I have the same problem when I am creating a TGFileDialog. On my mac it works, but on lxplus it crashes until I put the code after the new TGFileDialog in a function that I call, it is strange. To compile it I am not using O3 like in the first message but O2, but it is working on my mac. Is it a bug?
My code is part of a big class but at one time I have a function to open a file :
[code]//Open file from the batch
void Interface::OpenFile()
{
//Type for the files allowed
const char filetypes[] = {“ROOT files”, ".root"};
//Initial directory
TString directory("./Results");
TGFileInfo file_info;
file_info.fFileTypes = filetypes;
file_info.fIniDir = StrDup(directory);
//Open the dialox box
new TGFileDialog(gClient->GetRoot(), this, kFDOpen, &file_info);
//Save the name
TString path_file_batch(file_info.fFilename);
//Set up the parameters
SetUpBatch(path_file_batch);
}
[/code]
Like this it works on my Mac and Lxplus. But before I wrote the code of the SetUpBatch() function into the OpenFile() function like this :
[code]…
//Open the dialox box
new TGFileDialog(gClient->GetRoot(), this, kFDOpen, &file_info);
//Save the name
TString path_file_batch(file_info.fFilename);
//Display the name of the file
fTextEntryOpen->SetText(RemoveDirectory(path_file_batch));
[/code]
And only with this line it crashes… but not on my Mac though I am using exactly using the same Makefile.
I did’nt try yet, but could you try to change this:const char *filetypes[] = {"ROOT files", "*.root"}; like this (add 0, 0):const char *filetypes[] = {"ROOT files", "*.root", 0, 0};And let me know, please. (the 0 are used to mark the end of the arrays)
[quote]- Fix gcc3.x warnings using -fstack-check compiler flag:
warning: unreachable code at beginning of switch statement
As reported by Jacek M. Holeczek:
These warnings (strictly related to the “-fstack-check” option) seem
harmless, BUT THEY ARE NOT!
In fact, the gcc 3.x compiler produces code which leads to “core dumps”.[/quote]
Cheers,
Bertrand.
I will test this solution tomorrow on lxplus, but I managed to get the same error on my mac. When I launch my GUI on my Mac, my window is not “active” if I click on my open button linked to the function I have posted, it crashes, but if I click everywhere on my window to “active” it and after I click on the open button it is ok. However if I add the two 0 like you told me it works every time, so I will try on lxplus if it resolves also my problem.
I encountered the same problem and it does not behave that way that one could think immediately of a bug in the own code. Thanks to this forum I solved it but I think it is worth it to put an example to the documentation: