Bug 60912 - Profiling broken for optimized shared library projects
Summary: Profiling broken for optimized shared library projects
Status: RESOLVED NOT A BUG
Alias: None
Product: kdevelop
Classification: Applications
Component: Build tools: Automake (show other bugs)
Version: 2.1.3
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KDevelop Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-08 12:41 UTC by Craig Scott
Modified: 2003-07-09 16:06 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Craig Scott 2003-07-08 12:41:48 UTC
Version:           2.1.3 (using KDE KDE 3.1KDE 1.2)
Installed from:    RedHat RPMsRedHat RPMs
Compiler:          gcc 3.2 
OS:          Linux

Not sure if this is a KDevelop, libtool or gcc problem. I'll describe the steps to reproducing the bug and let you decide.

Start by creating a new terminal C++ project with the project wizard. Accept all default options. This will create a project with main.cpp as the only source file.

Add a new file called mylib.cpp in a subdirectory called "MyLibDir" below the main source directory. KDevelop asks for the library type - select shared library and accept defaults.

Add a second new file called wastetime.cpp in a subdirectory called "MyLibDir/WasteTime" and again select shared library with defaults.

Contents of mylib.cpp:

#include <iostream>

void WasteTime();
void RunLibTest()
{
  for (int i = 0; i<1000; ++i)
    WasteTime();
  std::cout << "Lib output" << std::endl;
}


Contents of wastetime.cpp:

void WasteTime()
{
  for (int i = 0; i<1000; ++i) ;
}


Contents of main.cpp:

void WasteTime();
void RunLibTest();
int main(int, char)
{
  for (int i = 0; i<1000; ++i)
    WasteTime();
  for (int i = 0; i<10; ++i)
    RunLibTest();
  return 0;
}



Now compile and run the project. Everything works fine.
Turn on profiling, rebuild and run. Again, the program runs to completion. Now, turn on optimizations, rebuild and run. The program exits with a core dump before anything is written to the terminal.

If this is a KDevelop bug, maybe some paths or libraries are being incorrectly set? My guess is that this is a libtool bug though. It might be good to understand this and see if it also appears in Gideon.
Comment 1 Roger Larsson 2003-07-08 13:18:38 UTC
Try to run your program from command line - does it still core dump?  
 
Comment 2 Amilcar do Carmo Lucas 2003-07-08 13:48:13 UTC
I think this is a bug from the 2.1.X versions. 
 
Could not duplicate it in KDevelop3.0 from CVS HEAD 
 
Comment 3 Craig Scott 2003-07-09 01:39:54 UTC
Yes, it still core dumps when run from the command line. 
 
In case it is relevant, my system is a standard Red Hat 8.0 install with 
updates applied. KDE version is 3.0.5a (the KDE bug reporting system would not 
let me report a bug unless I said I had at least 3.1 !!!). 
 
Comment 4 Thiago Macieira 2003-07-09 02:13:17 UTC
Can you tell us where it core-dumped? Maybe a backtrace? 
 
Comment 5 Craig Scott 2003-07-09 02:20:11 UTC
Backtrace doesn't seem to give much of a hint: 
 
test % gdb .libs/lt-test core.1471 
GNU gdb Red Hat Linux (5.2.1-4) 
Copyright 2002 Free Software Foundation, Inc. 
GDB is free software, covered by the GNU General Public License, and you are 
welcome to change it and/or distribute copies of it under certain conditions. 
Type "show copying" to see the conditions. 
There is absolutely no warranty for GDB.  Type "show warranty" for details. 
This GDB was configured as "i386-redhat-linux"... 
Core was generated by `lt-test'. 
Program terminated with signal 11, Segmentation fault. 
Reading symbols from 
/hiddenpath/KDevelopTest/test/test/MyLibDir/.libs/libMyLibDir.so.0...done. 
Loaded symbols for 
/hiddenpath/KDevelopTest/test/test/MyLibDir/.libs/libMyLibDir.so.0 
Reading symbols from 
/hiddenpath/KDevelopTest/test/test/MyLibDir/WasteTime/.libs/libWasteTime.so.0...done. 
Loaded symbols for 
/hiddenpath/KDevelopTest/test/test/MyLibDir/WasteTime/.libs/libWasteTime.so.0 
Reading symbols from /usr/lib/libstdc++.so.5...done. 
Loaded symbols for /usr/lib/libstdc++.so.5 
Reading symbols from /lib/libgcc_s.so.1...done. 
Loaded symbols for /lib/libgcc_s.so.1 
Reading symbols from /lib/i686/libm.so.6...done. 
Loaded symbols for /lib/i686/libm.so.6 
Reading symbols from /lib/i686/libc.so.6...done. 
Loaded symbols for /lib/i686/libc.so.6 
Reading symbols from /lib/ld-linux.so.2...done. 
Loaded symbols for /lib/ld-linux.so.2 
#0  0x40017729 in WasteTime() () at wastetime.cpp:2 
2       { 
(gdb) bt full 
#0  0x40017729 in WasteTime() () at wastetime.cpp:2 
        i = 999 
#1  0x080486dd in main () at main.cpp:6 
        i = 999 
#2  0x420158f7 in __libc_start_main () from /lib/i686/libc.so.6 
No symbol table info available. 
 
Comment 6 Thiago Macieira 2003-07-09 02:38:17 UTC
Sorry, I have no idea. The backtrace doesn't show anything out of the ordinary. 
 
I'd say this is either a linker or library bug. 
 
Can you try compiling manually (i.e., without libtool)? If that doesn't crash, can you also test the 
non lt- version of the program? 
Comment 7 Craig Scott 2003-07-09 02:58:47 UTC
I copied libMyLibDir.so.0 and libWasteTime.so.0 to the same directory as the 
test executable (ie the non-libtool version created by the build) so that the 
non-libtool binary could find them. Ran it but had the same core dump problem. 
 
I also tried a separate build (in fresh directories) where I did all the 
compiling manually: 
 
cd MyLibDir/WasteTime 
g++ -O2 -pg -g3 -fPIC -o libwastetime.so -shared wastetime.cpp 
cd .. 
g++ -O2 -pg -g3 -fPIC -o libmylib.so -shared mylib.cpp 
cd .. 
g++ -O2 -pg -g3 -c main.cpp 
g++ -O2 -pg -g3 main.o MyLibDir/libmylib.so MyLibDir/WasteTime/libwastetime.so 
 
ldd reports that a.out finds the required libraries just fine. However, this 
a.out still causes a core dump as before. Clearly, this is not a KDevelop or 
libtool bug, but probably a gcc thing. Any suggestions where else I should 
report this? 
 
Comment 8 Amilcar do Carmo Lucas 2003-07-09 16:06:54 UTC
This is not a KDevelop bug. 
Maybe report it to the GNU libtool guys