When I try to run lazarus, it crashes with the following error: GTKWindowStateEventCB SplashForm:TSplashForm new_window_state=0 changed_mask=1 GTKWindowStateEventCB SplashForm:TSplashForm 0 [RMVDStPr] TApplication.IconChanged - TODO: convert this message...no implementation in gtk or win32 Note: environment config file not found - using defaults [TMainIDE.Destroy] A [TMainIDE.Destroy] B -> inherited Destroy... TMainIDE [TMainIDE.Destroy] END [FORMS.PP] ExceptionOccurred Sender=EInvalidOp Exception=Invalid floating point operation Stack trace: $00002B98BF14F37E $C0985D025AEE631F TApplication.HandleException Invalid floating point operation Stack trace: $00002B98BF14F37E $C0985D025AEE631F [FORMS.PP] ExceptionOccurred I have tried to make a backtrace but, when I type bt in gdb, I get a "No stack" message. emerge --info ****************************************** Portage 2.1.2-r10 (default-linux/amd64/2006.1/desktop, gcc-4.1.2, glibc-2.5-r0, 2.6.19-gentoo-r4 x86_64) ================================================================= System uname: 2.6.19-gentoo-r4 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 22 Feb 2007 17:20:02 +0000 dev-java/java-config: 1.3.7, 2.0.31-r3 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.20 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon64 -O2 -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS=" http://ftp.romnet.org/gentoo/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.ro.gentoo.org/gentoo-portage" USE="7zip X a52 aac acl acpi alsa amd64 aoss apache2 arj asf authdaemond authfile authlib berkdb bitmap-fonts bzip2 cairo cdparanoia cdr clamav cli cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode exif ffmpeg firefox flac fortran gdbm gif gnome gpm gstreamer gtk gtk2 hal iconv imagemagick iproute2 isdnlog java jpeg libg++ mad matroska midi mikmod mono mp3 mpeg mysql ncurses nls nptl nptlonly nsplugin ogg opengl oss pam pcre pdf perl php png postgres ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl svg tcpd theora threads tiff tk truetype truetype-fonts type1-fonts unicode usb vorbis wmf xine xml xorg xpm xv xvid zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS ***************************** emerge -pv fpc lazarus [ebuild R ] dev-lang/fpc-2.0.4 USE="source -doc" 0 kB [ebuild R ] dev-lang/lazarus- 0.9.20 0 kB
To rule out problems caused by other packages, could you please check if the problem also exists with the binaries provided at <http://sourceforge.net/project/showfiles.php?group_id=89339> ?
(In reply to comment #1) > To rule out problems caused by other packages, could you please check if the > problem also exists with the binaries provided at > <http://sourceforge.net/project/showfiles.php?group_id=89339> ? > I tried with lazarus-0.9.20-0.x86_64.rpm and after I made a symlink for libgdk_pixbuf-2.0.so (ln -sf /usr/lib64/libgdk_pixbuf-2.0.so /usr/lib64/libgdk_pixbuf.so.2) the IDE started.However the default project didn't compile because some libraries were missing. (Linking /tmp/project1 /usr/bin/ld: cannot find -lgdk_pixbuf).
(In reply to comment #2) > I tried with lazarus-0.9.20-0.x86_64.rpm and after I made a symlink for > libgdk_pixbuf-2.0.so (ln -sf /usr/lib64/libgdk_pixbuf-2.0.so > /usr/lib64/libgdk_pixbuf.so.2) the IDE started.However the default project > didn't compile because some libraries were missing. (Linking /tmp/project1 > /usr/bin/ld: cannot find -lgdk_pixbuf). Ah, sorry, the official binaries are GTK1 versions, while the ebuild installs the GTK2 version. (And please remove that symlink, it's very likely to break stuff when it gets used.) It's good to know that the GTK1 version does work on your system, though. I've asked for some help to check if the GTK2 version works on other amd64 systems, to see if this might be amd64-specific, because lazarus is starting without problems on my x86 system.
(In reply to comment #3) > (In reply to comment #2) > > I tried with lazarus-0.9.20-0.x86_64.rpm and after I made a symlink for > > libgdk_pixbuf-2.0.so (ln -sf /usr/lib64/libgdk_pixbuf-2.0.so > > /usr/lib64/libgdk_pixbuf.so.2) the IDE started.However the default project > > didn't compile because some libraries were missing. (Linking /tmp/project1 > > /usr/bin/ld: cannot find -lgdk_pixbuf). > > Ah, sorry, the official binaries are GTK1 versions, while the ebuild installs > the GTK2 version. (And please remove that symlink, it's very likely to break > stuff when it gets used.) It's good to know that the GTK1 version does work on > your system, though > > I've asked for some help to check if the GTK2 version works on other amd64 > systems, to see if this might be amd64-specific, because lazarus is starting > without problems on my x86 system. > I already removed that symlink just after I have removed the binary package :) I have compiled lazarus at work on a Gentoo x86 box and it started without errors, so it is possible that this is an AMD64 problem(or my Gentoo box is broken), although some time ago I have used Lazarus on my Gentoo AMD64 box. I'll try to make a backtrace and post it here and I'll also try to downgrade lazarus and fpc to see if the problem persists.
I tried to create a backtrace for lazarus, but when I run bt command in gdb, I still receive "No stack message".Though I managed to get a more detailed error: Starting program: /usr/bin/startlazarus shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory [Thread debugging using libthread_db enabled] [New Thread 47916698317088 (LWP 22466)] GTKWindowStateEventCB SplashForm:TSplashForm new_window_state=0 changed_mask=1 GTKWindowStateEventCB SplashForm:TSplashForm 0 [RMVDStPr] TApplication.IconChanged - TODO: convert this message...no implementation in gtk or win32 [TMainIDE.Destroy] A [TMainIDE.Destroy] B -> inherited Destroy... TMainIDE [TMainIDE.Destroy] END [FORMS.PP] ExceptionOccurred Sender=EInvalidOp Exception=Invalid floating point operation Stack trace: $00002B0C4A7DC37E CODEEXPLOPTS_finalize, line 104 of debugoptionsfrm.pas $C0985D025AEE631F CODEEXPLOPTS_finalize, line 104 of debugoptionsfrm.pas TApplication.HandleException Invalid floating point operation Stack trace: $00002B0C4A7DC37E CODEEXPLOPTS_finalize, line 104 of debugoptionsfrm.pas $C0985D025AEE631F CODEEXPLOPTS_finalize, line 104 of debugoptionsfrm.pas [FORMS.PP] ExceptionOccurred Program exited normally. (gdb) bt No stack. (gdb) I have compiled the sources from lazarus 0.9.21 and the error persists.
After clearing my ~/.lazarus and starting lazarus, these messages come up: [...] TApplication.IconChanged - TODO: convert this message...no implementation in gtk or win32 Note: environment config file not found - using defaults GTKWindowStateEventCB :TPromptDialog new_window_state=0 changed_mask=1 GTKWindowStateEventCB :TPromptDialog 0 [RMVDStPr] NOTE: editor options config file not found - using defaults NOTE: miscellaneous options file not found - using defaults NOTE: codetools config file not found - using defaults [...] which again brings up the possibility that the bug is really in the GTK2 code called by PromptDialog (asking the user to set the fpc source path later). Everything from [TMainIDE.Destroy] onwards, including your problem getting a sane stack trace, appears to be a result of lazarus attempting to clean up and exit nicely rather than just bombing out. By the time you type "bt" in gdb, the program has quit. If you can, would you please look in lcl/include/application.inc for "CaptureExceptions := True" (line 106), comment it out, rebuild lazarus, and try to get a backtrace from gdb again?
> which again brings up the possibility that the bug is really in the GTK2 code > called by PromptDialog (asking the user to set the fpc source path later). > > Everything from [TMainIDE.Destroy] onwards, including your problem getting a > sane stack trace, appears to be a result of lazarus attempting to clean up and > exit nicely rather than just bombing out. By the time you type "bt" in gdb, the > program has quit. If you can, would you please look in > lcl/include/application.inc for "CaptureExceptions := True" (line 106), comment > it out, rebuild lazarus, and try to get a backtrace from gdb again? > I tried to do as you suggested but I got the same result . I'll play some more with gdb at work(if I'll have some free time) to see if I can manage to find a suitable breakpoint just before that exception is raised.
I have built a new Gentoo AMD64 and Lazarus started with no errors in Fluxbox(there are still some errors at compiling an empty project). After emerging Gnome, I have tried to run startlazarus from Gnome, and I got exactly the same errors as the on my main Gentoo box. I tried to run Lazarus, from fluxbox, on my main Gentoo box, and it started with no errors. So it seems Lazarus crashes at startup only if I use Gnome as a DM.
Thanks, that's very useful. Unfortunately though, I'm still not able to reproduce this on x86, even in GNOME... If you're still willing to debug, and if you're still looking for a good breakpoint, could you step through TMainIDE.LoadGlobalOptions (from ide/main.pp)?
(In reply to comment #9) > Thanks, that's very useful. Unfortunately though, I'm still not able to > reproduce this on x86, even in GNOME... > > If you're still willing to debug, and if you're still looking for a good > breakpoint, could you step through TMainIDE.LoadGlobalOptions (from > ide/main.pp)? > Sure. I have just started looking into the code. I'm not very good at this but I will try to see if I can find what causes the exception.
I have found what causes the exception. It is the procedure SetupFPCSourceDirectory, when it is called with the InteractiveSetup argument. If I comment out that line, and recompile lazarus, I finally manage to start lazarus under Gnome on my Gentoo AMD64. I'll try to debug that procedure tomorrow. It seems that in Fluxbox there is no exception raised, but the FPC source is not properly set because I cannot compile any project.
I have finally found what caused the errors. In the file ide/include/unix/lazbaseconf.inc there are some predefined paths for the fpc source. In the fpc-2.0.4.ebuild the INSTALL_SOURCEDIR is set to "${D}"/usr/lib/fpc/${PV}/source , and therefore the fpc sources are build in the folder /usr/lib/fpc/2.0.4/source. But since this path it is not found in the lazbaseconf.inc file, lazarus doesn't know were to look for the fpc source file. The error will only appear if there is no .lazarus folder in home directory, because then it tries to find it calling the procedure FindDefaultFPCSrcDirectory. IMHO there are more possible resolution for this issue: 1)create a symlink from /usr/lib/fpc/2.0.4/source to one of the paths specified in lazbaseconf.inc 2)Modifying the lazbaseconf.inc file and add the folder /usr/lib/fpc/2.0.4/source, and also changing the DefaultFPCSrcDirs upper index limit to 15. Since lazarus-0.9.20 is build for fpc-2.0.4, I think that creating a patch for that file is the best solution. 3)Modifying the fpc-2.0.4 ebuild so that the fpc sources will be installed in an appropriate path. Tomorow I will try to see why on Gentoo x86 this doesn't happen. Thanks for pointing out where to look in the lazarus sources.
Thank you very much for looking into this. (In reply to comment #12) > 2)Modifying the lazbaseconf.inc file and add the folder > /usr/lib/fpc/2.0.4/source, and also changing the DefaultFPCSrcDirs upper index > limit to 15. Since lazarus-0.9.20 is build for fpc-2.0.4, I think that creating > a patch for that file is the best solution. Yes, you're right, that would be good, and I'll try to get that added soon. It would only be a workaround at best for this bug, though. On x86, lazarus starts with a dialog box "Free Pascal Sources not found", telling the user that the path can be set in the environment options. (This is what I too briefly mentioned in comment #6.) On amd64, it should start with the same dialog box. The fact that the sources cannot be found automatically is expected. But workaround or not, it /would/ actually make lazarus usable. :)
Created attachment 112679 [details, diff] This patch modifies the lazbaseconf.inc file so that the fpc-2.0.4 sources will be found by lazarus
(In reply to comment #13) > Thank you very much for looking into this. > > (In reply to comment #12) > > 2)Modifying the lazbaseconf.inc file and add the folder > > /usr/lib/fpc/2.0.4/source, and also changing the DefaultFPCSrcDirs upper index > > limit to 15. Since lazarus-0.9.20 is build for fpc-2.0.4, I think that creating > > a patch for that file is the best solution. > > Yes, you're right, that would be good, and I'll try to get that added soon. It > would only be a workaround at best for this bug, though. On x86, lazarus starts > with a dialog box "Free Pascal Sources not found", telling the user that the > path can be set in the environment options. (This is what I too briefly > mentioned in comment #6.) On amd64, it should start with the same dialog box. > The fact that the sources cannot be found automatically is expected. > > But workaround or not, it /would/ actually make lazarus usable. :) I have created a patch and updated the ebuild and I will attach them here. Even though this is a workaround I think it is a good thing that lazarus will now find the fpc source folder and it is not necesary to specify it. I have also filed a bug on freepascal bugtracker. Maybe they would give an ideea why a exception is raised when a messagebox is displayed. When I'll get home I will also try to create a project that displays a message box and run it in Gnome, to see what happens.
Created attachment 112680 [details] Ebuild for lazarus-0.9.20 with patch
Thanks. I've modified your patch a bit to not hardcode the fpc version, and now that the sources get patched anyway, I've made sure the default LCL interface gets set to gtk2. I'll keep this bug open until the issue that actually caused your crash is fixed, or if you can't manage to trigger it anymore.
Created attachment 112778 [details] backtrace for a project that should display a messagedlg box
librsvg, huh? Could you see what happens when you rebuild cairo with USE=-svg? I'll see if I can see something more useful with +svg myself, too.
Also, which icon set did you choose in GNOME? The default?
(In reply to comment #19) > librsvg, huh? Could you see what happens when you rebuild cairo with USE=-svg? > I'll see if I can see something more useful with +svg myself, too. > I have compiled cairo without the svg useflag, and the there's no change. I have tried with all the icon themes from a default gnome installation and when the message dialog should appear, that exception is raised. In Theme Manager, from "Theme Details" I have changed the controls theme (I guess that's the gtk engine) and with some themes the application displayed the message dialog. The control themes that worked are : the low contrast themes , large print, redmond, the high contrast themes. With all other themes, the application crashed(clearloox, crux, glider, industrial, mist, raleigh, simple, thinice).
Sorry, that was due to my own misunderstanding. librsvg is not used by cairo, but rather by GTK+ directly (and the only way to stop it is to remove it, which is not a good idea if it's depended upon by any application)
(In reply to comment #22) > Sorry, that was due to my own misunderstanding. librsvg is not used by cairo, > but rather by GTK+ directly (and the only way to stop it is to remove it, which > is not a good idea if it's depended upon by any application) > librsvg seems to be used by nautilus (and other apps that are not so important) so I guess it is not a good thing to remove it. Should I file a bug to http://bugzilla.gnome.org/ ?
No, it's more likely that the bug is probably in lazarus, merely getting exposed by librsvg.
(In reply to comment #24) > No, it's more likely that the bug is probably in lazarus, merely getting > exposed by librsvg. > I forgot the mention that I have filed a bug to the Lazarus bug tracker : http://www.freepascal.org/mantis/view.php?id=8396 and posted a topic on the lazarus forum : http://www.lazarus.freepascal.org/index.php?name=PNphpBB2&file=viewtopic&t=3446 Thanks for all the help.
I've put a patch in the tree that avoids storing a pointer in a 32-bit variable. I've not revbumped lazarus, because the patch is incomplete: welp tested it for me and could still get LCL dialog apps to crash. However, since it crashed slightly differently for him, the patch might be useful for you. Could you (after a couple of hours) resync your tree, install lazarus again, making sure the lcl-handle patch got applied, and test your own program once more? If it works for you, I'll update the patch a bit (so that it doesn't break non-GTK2 builds) and send it upstream.
(In reply to comment #26) > I've put a patch in the tree that avoids storing a pointer in a 32-bit > variable. I've not revbumped lazarus, because the patch is incomplete: welp > tested it for me and could still get LCL dialog apps to crash. However, since > it crashed slightly differently for him, the patch might be useful for you. > Could you (after a couple of hours) resync your tree, install lazarus again, > making sure the lcl-handle patch got applied, and test your own program once > more? > > If it works for you, I'll update the patch a bit (so that it doesn't break > non-GTK2 builds) and send it upstream. > I have resynced the portage tree and reinstall lazarus. The lcl-handle patch was applied, but the exception is still present:(
Fixed in 0.9.22, and now I've been able to actually verify it.
Actually... considering the current patch is just a workaround, this should probably stay open.
Fixed now. You were right, I should have brought this to the librsvg folks... The bug was in there after all. librsvg-2.16.1-r1 is now in the tree, with a patch, and I've added lazarus-0.9.22-r1 which removes the workaround patch, and instead installs only with a non-broken librsvg.
(In reply to comment #30) > Fixed now. You were right, I should have brought this to the librsvg folks... > The bug was in there after all. librsvg-2.16.1-r1 is now in the tree, with a > patch, and I've added lazarus-0.9.22-r1 which removes the workaround patch, and > instead installs only with a non-broken librsvg. > Sorry for the late reply, I was away from the computer for a week and a half. Now I am using another theme for controls, named Whiteplate, and with this theme, lazarus works ok even in Gentoo on a AMD64 arch. I'll rebuild lazarus and see if with the old theme, lazarus will crash or not, and post the results here. Thanks
I have just tested lazarus and a project that displays a message dialog with two of the themes that I used before, and now there no more crashes. Thanks again:)
