Crash when displaying graphics - Cygwin/X


I did a basic install of cygwin/x and root using the latest binary on the website (5.32.00). I extracted the root binary, set my paths, and root works if I don’t use any graphics. However, as soon as I draw anything root hangs and I get a stackdump looking like the following


Stack trace: Frame Function Args 0026613C 754E1194 (00000338, 0000EA60, 00000000, 00266270) 00266150 754E1148 (00000338, 0000EA60, 000000A4, 0026624C) 00266270 610DA9B9 (6119A7CC, 00000000, 00000000, 00000000) 00266340 610DB1F7 (0028CE80, 00000006, 00266390, 6102FDAD) 00266350 610DB397 (00000001, 00000006, 00266380, 610D847C) 00266390 6102FDAD (FFFEFEDF, 0028CE80, 00000000, 001E001C) 002664A0 61030B40 (00000338, 0000EA60, 000000A4, 0026659C) 002665C0 610DAA72 (00000000, 00001000, 00001000, 00001000) 002666B0 610D7E2E (00000000, 00000018, 00000018, 6CE32DC9) 00266710 610D82FE (00000400, 20514A38, 00000400, 00000006) 002667C0 610D8450 (000010BC, 00000006, 00266830, 6CE40138) 002667E0 610D847C (00000006, 0028CE80, 00266810, 00000000) 00266810 610D8705 (6CE40144, 20000000, 00000001, 206BDCF4) 002668B0 6110EBF5 (00266910, 20513B30, 00000000, 6CE05949) 00266950 71841AC1 (20513B30, 00000000, 00000000, 00000000) 002669C0 7183037F (20513B30, 0000048D, 0007241F, 00266A04) End of stack trace (more stack frames may be present)
Other programs work fine with my cygwin/x server such as gvim. I dont have many clues what is wrong, I’m using the latest gcc-core and gcc-g++ versions (4.5.3). Can anyone provide help on how to fix this?


Which version of root did you download (exact file name)?
Do you start root from a xterm?

Cheers, Bertrand.

I used root_v5.32.00.win32gcc-gcc-4.3.tar.gz and I did start root from an xterm.

I just tried compiling from source also, but I am getting a very similar result from this post: [unsolved] fresh cygwin and root 5.32 broken build

with the error

make: *** [graf3d/g3d/src/G__G3D.cxx] Floating point exception (core dumped) make: *** Deleting file `graf3d/g3d/src_G__G3D.cxx`

It’s not essential to build from source, but it may be related?

Well, this looks more like a bug in cygwin/make/gcc, and didn’t have this problem building ROOT so far…
But let me ask again: which tar file did you try exactly?

Cheers, Bertrand

I just edited my last post to include that filename, after realizing your specific question.

And I built from the latest trunk, I’m going to try downgrading to gcc-4.3.4 as you use instead of 4.5.3 and see if that helps.

Please wait before downgrading, as I use gcc4.5 now to build binaries (I have to verify the version on the web)

OK, I’m trying to build win32gcc binaries with the actual svn trunk version of ROOT. Stay tuned (I’ll let you know when its done).

Sure, I appreciate the effort for this.

Hi, no problem building svn trunk. Here is the binary: … 4.5.tar.gz
Could you try and let me know?

Cheers, Bertrand.


Thank you very much, this build works great without any problems. Would you be able to post some settings (configure parameters, or anything else) that went into making this? I will compare and see if I can tell where the error occurred.

I’m glad this setup is now working.

Here is the config used to build it:

./configure win32gcc --enable-cintex --enable-gdml --enable-genvector --enable-mathmore --en able-memstat --enable-minuit2 --enable-mysql --enable-odbc --enable-python --ena ble-qt --enable-qtgsi --enable-reflex --enable-ruby --enable-roofit --enable-tab le --enable-tmva --enable-unuran --enable-builtin-zlib --with-fftw3-incdir=/usr/ include --with-fftw3-libdir=/usr/lib --with-gsl-incdir=/usr/include --with-gsl-l ibdir=/usr/lib --with-python-incdir=/usr/include/python2.6 --with-python-libdir= /usr/lib --with-pythia6-libdir=/home/bellenot/libs/pythia6 --with-qt-incdir=/usr /lib/qt4/include --with-qt-libdir=/usr/lib/qt4/lib
And BTW, why are you using cygwin/X/win32gcc, and not the native win32 one?

Cheers, Bertrand.

Hi Bertrand,

I’m not sure his response, but here’s mine. The VC++ version is a pain in the a$$. You can’t use it with xterm/mrxvt (and I have yet to find anything close to a reasonable terminal that you can use with it; console2 is the best I’ve found and it’s pretty horrible in comparison). You can’t use the same Makefiles that work with Linux. It doesn’t recognize softlinks (which is a real loss). And I’ll let you try to build the CMS event display with it :slight_smile:. (Admittedly, getting it to build with the gcc version wasn’t a lot of fun, but I got it to build).

The VC++ version is much faster and if I had to design a DAQ on Windows, I’d almost certainly use it instead of the gcc version. But the GCC version is so much more like root on linux that there are many many advantages of using it as well.

There is a large fraction of users who use linux at work but have Windows laptops. I am still somewhat baffled by why it has taken the Root team (and by no means do I just mean Bertrand) so long to realize that the Cygwin gcc version offers a lot of advantages for this large fraction of their user base.


Hi Charles,

Yes, I know why many users use cygwin/X/gcc, but another solution could be to use a (or several) virtual machine (I have native Windows and several VMs)
And BTW, I had a version of the CMS event display (Fireworks) working on Windows long time ago (ok, I agree, it was not easy :wink:)

Cheers, Bertrand.

The VM solution is very nice for some things, but it’s quite heavy. I played with it a couple years ago and it still was not as transparent to setup as I would have liked. If CERN got behind this a bit more, e.g., set it up so that it was easy to download the VM and then ssh into it from the Windows/cygwin side and display things via X (and they may well have by now), then this option can be useful to many people. But this still isn’t a replacement for Cygwin/gcc root.

(If you do have any ideas for a terminal that isn’t so painful to run VC++ root on, I’d love to hear them! :slight_smile: )



p.s. For those who are not at CERN/in HEP, I think the bar is considerably higher for using VMs. In that case, without a very concrete example setup, I think this is currently a no-go. In this case, Cygwin/gcc is pretty much the only viable alternative and its really too bad that this isn’t much better supported.

I am using cygwin because I need to be in a windows enviornment, but refuse to mess with visual studio. I am a linux user, so makefiles and gcc are much easier for me to understand. I thought about using a virtual machine also, would using a virtual machine on an average machine by today standards be as fast or faster as using the cygwin installation for root scripts and macros? (note that I am not doing cern specific tasks).

Virtual machines are very powerful nowadays, and you have a complete OS! (and you can choose your flavor) :wink:

Cheers, Bertrand.

But setting them up is a pain. If working though CERN, then there are (were?) couple options. If you are not, then it’s a hard route to follow by yourself.

Not at all, there are a couple of free VM players out there, easy to install, and then simply download a free image of you preferred OS… (i was using VM before being at CERN)

Picking a VM, setting it up so you can ssh into it (reliably - this was a complete pain in my case), installing root, etc. is much, much more difficult than unzipping a tarball of pre-built cygwin gcc root installation.

On Bertrand’s suggestion I reconsidered using virtual machines … and it is very nice! Running fedora on a laptop is pretty quick once you switch to something other than gnome as a windows manager. I am not involved in the cern collaboration (completely different field) so for me running on a laptop is good enough. Also, backing up my system can be as effortless as saving the image file.

Thanks for everyone’s efforts and insightful opinions!