aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Author Topic: crash due to compile with --enable-optimize ?  (Read 2897 times)

Arichy

  • Full Member
  • ***
  • Karma: 0
  • Offline Offline
  • Posts: 224
crash due to compile with --enable-optimize ?
« on: January 03, 2006, 11:24:50 AM »

Hello,

after reading http://www.amule.org/wiki/index.php/Configure and http://www.amule.org/wiki/index.php/Compilation_Installation yesterday I compiled 2.1.0 for Linux with
Code: [Select]
./configure  --disable-nls --disable-debug --enable-optimize --disable-dependency-tracking and amule crashed (grey froze) after two hours running nice fast on my Pentium 166 MMX. Then I compiled like I did everytime before with
Code: [Select]
./configure  --disable-nls --disable-debug and now amule runs very slow for 24h. Has that something to do with the --enable-optimization option ? I think some years ago there was a warning about enabling optimisation (the old name). When so, there should be a warning in the wiki / configure --help
Logged
Gentoo i686

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: crash due to compile with --enable-optimize ?
« Reply #1 on: January 03, 2006, 04:44:33 PM »

the optimize should never cause a crash. Keyword being "should"
Logged

Arichy

  • Full Member
  • ***
  • Karma: 0
  • Offline Offline
  • Posts: 224
Re: crash due to compile with --enable-optimize ?
« Reply #2 on: January 05, 2006, 07:15:21 PM »

I compiled a fresh amule 2.1.0 source tree again with
Code: [Select]
./configure  --disable-nls --disable-debug --enable-optimize and it runs now for 36h. So the code optimized compile was probably not the reason for the crash mentioned above.
Logged
Gentoo i686

Gerd78

  • Hero Member
  • *****
  • Karma: 9
  • Offline Offline
  • Posts: 681
Re: crash due to compile with --enable-optimize ?
« Reply #3 on: January 05, 2006, 07:41:35 PM »

Without any stdout/stderr output (literal copies, no "it crashed" summaries) it's impossible to tell the reason of the crash. It might be related to optimisations, but it might also be pure coincidence...

There are some rare cases where optimisations produce incorrect code. I had such a case recently with another application (ReZound): GCC 3.3 produced correct code with and without -O2, but GCC 4.0 produced correct one without and incorrect one with -O2.

In most cases these are GCC bugs. If you can, isolate them into the smallest possible code snippet which shows the problem and attach it to a bug report at http://gcc.gnu.org/bugs.html

Please note that reports such as this one are not OK there; you will have to give at least the exact GCC version number and more background information.
Logged