[Gambas-user] Error on installing last svn

[Benoit Minisini]

On samedi 08 septembre 2007, ron wrote:
> On Saturday 08 September 2007 20:06, Benoit Minisini wrote:
> > On samedi 08 septembre 2007, ron wrote:
> > > same as:
> > > [Gambas-user] svn 552 , can't install (R.Stormo)
> > > Benoit did ask for some debug and other info.
> > > I have the same error with svn 556 and reported this.
> > > Included strace part of the gbi2 process.
> > >
> > > The strange thing to me is using 'gbi2 -p' do:
> > > gb.qt.kde.html
> > > gb.debug
> > > ...
> > > gb.qt.ext
> > > gb.qt.opengl
> > > gb.qt
> > > Segmentation fault
> > >
> > > And 'gbi2 -p gb.qt.kde.html' gives it in gb.qt.kde.html which passed
> > > first.
> > >
> > > :(
> > >
> > > Ron
> >
> > Do you both use the same distribution?
>
> Kubuntu 6.10
>
> Regarding KDE which libs/includes should be there?
>
> I will do check all *.h files in the gambas source for used includes of *.h
> files to check they exists in the /usr/include path. (special the kde
> related) Maybe a file in the -dev package has a different name in
> (k)ubuntu.
>
> However this look to me not a reason for 'Segmentation fault'.
> I understand here is something going wrong with allocated memory.
> Second,  if the includes of *.h where the fault should it not reported
> during 'make'? Third, it occurs during make install so all  compiling
> should already be done. Fourt, it occurs with gbi2
>
> I had this same error in the past with SuSE also and it was a error during
> read of a file for the info to gather.
> I do not remember how it was solved by me other then correcting something
> with the file open/read in  gbi code to prevent fatal crash abort.
> This was reported at that time and never heard something.
>
> autoconf --version
> autoconf (GNU Autoconf) 2.60
>
> automake --version
> automake (GNU automake) 1.9.6
>
> kde-config --version
> Qt: 3.3.6
> KDE: 3.5.5
> kde-config: 1.0
>
> Ron
>

The crash occurs inside the ld.so library. But gbi does not use it directly, 
it relies of the GNU libtool package. So there are three possibilites:
1) A bug in ld.so.
2) A bug in libtool that makes ld.so crash.
3) A bug somewhere else that corrupts the memory and make ld.so crash.

The ast fix removed the use of libtool on Linux, by using dl*() API directly. 
But Laurent told that it changes nothing. So libtool seems to not be the 
problem.

I asked him to try with valgrind to see if there is memory corruption.

I tried to pass some new flags to the dlopen() API that loads the shared 
library too. Maybe it could change something.

Let's see...

-- 
Benoit Minisini