Timo Sirainen wrote:
On Wed, 2010-07-21 at 13:52 -0400, Chris Hoogendyk wrote:
Once I got rid of the optimization (it still has -O) within that subdirectory of the source, I can't get it to fail. It seems to be just working.
If you enable optimizations again, does it start breaking? Instead of the gdb prints, I could also give a patch to make it log the same things.
I've anyway been running Dovecot on Solaris/Sparc for years and I haven't gotten this same signal 10, even though this is in the generic index file handling code..
Sorry for the delay in responding. We switched servers and were totally caught up in the switch and getting things worked out through the end of Friday. Recovered now. The server is in full service now. Still some glitches to be worked out.
Anyway, the testing I did with Dovecot before we went into production was a bit hurried. When we went into production, there were other components doing the same thing with signal 10 and core dumping. I went back and recompiled all of Dovecot with optimization dropped back to -O only. Then everything worked, and it has proved to be one of the faster, more reliable pieces of the transition.
I should note that we are using gccfss, and I had been using -g -fast in my build environment. That -fast translates into a couple of different things. Anyway, gccfss is the CoolTools implementation that is a gcc front end to the Sun Studio backend. So, the actual code generation is being done with Sun Studio, even though the front end is gcc, gnu make, etc. I also had -xtarget=ultraT2. So our environment may be different from your past experience with Solaris/Sparc.
Since we are now in production, we can't do any tests to see if they re-introduce errors. I think it's pretty clear that the -O2 and -fast with gccfss caused problems.
--
Chris Hoogendyk
- O__ ---- Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center
<hoogendyk@bio.umass.edu>
---------------
Erdös 4