|
From: Kolja K. <ko...@fr...> - 2021-11-11 09:42:38
|
Hi all,
while testing some newly created gig-files I ran into some problems with gigedit. I think, this might have something to do with my installation of it.
When trying to install tha latest gegedit version (1.2.0), running
./configure
runs alright, but then make will give:
In file included from builtinpix.cpp:2:
../compat.h:194:21: error: ‘const Pango::Alignment Pango::ALIGN_LEFT’ redeclared as different kind of entity
194 | const Alignment ALIGN_LEFT = Alignment::LEFT;
| ^~~~~~~~~~
In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
from /usr/include/gtkmm-3.0/gtkmm/box.h:27,
from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27,
from ../compat.h:134,
from builtinpix.cpp:2:
/usr/include/pangomm-1.4/pangomm/layout.h:77:3: note: previous declaration ‘Pango::Alignment Pango::ALIGN_LEFT’
77 | ALIGN_LEFT,
| ^~~~~~~~~~
In file included from builtinpix.cpp:2:
../compat.h:194:45: error: ‘LEFT’ is not a member of ‘Pango::Alignment’
194 | const Alignment ALIGN_LEFT = Alignment::LEFT;
| ^~~~
../compat.h:195:21: error: ‘const Pango::Alignment Pango::ALIGN_CENTER’ redeclared as different kind of entity
195 | const Alignment ALIGN_CENTER = Alignment::CENTER;
| ^~~~~~~~~~~~
In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
from /usr/include/gtkmm-3.0/gtkmm/box.h:27,
from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27,
from ../compat.h:134,
from builtinpix.cpp:2:
/usr/include/pangomm-1.4/pangomm/layout.h:78:3: note: previous declaration ‘Pango::Alignment Pango::ALIGN_CENTER’
78 | ALIGN_CENTER,
| ^~~~~~~~~~~~
In file included from builtinpix.cpp:2:
../compat.h:195:47: error: ‘CENTER’ is not a member of ‘Pango::Alignment’
195 | const Alignment ALIGN_CENTER = Alignment::CENTER;
| ^~~~~~
../compat.h:196:21: error: ‘const Pango::Alignment Pango::ALIGN_RIGHT’ redeclared as different kind of entity
196 | const Alignment ALIGN_RIGHT = Alignment::RIGHT;
| ^~~~~~~~~~~
In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
from /usr/include/gtkmm-3.0/gtkmm/box.h:27,
from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27,
from ../compat.h:134,
from builtinpix.cpp:2:
/usr/include/pangomm-1.4/pangomm/layout.h:79:3: note: previous declaration ‘Pango::Alignment Pango::ALIGN_RIGHT’
79 | ALIGN_RIGHT
| ^~~~~~~~~~~
In file included from builtinpix.cpp:2:
../compat.h:196:46: error: ‘RIGHT’ is not a member of ‘Pango::Alignment’
196 | const Alignment ALIGN_RIGHT = Alignment::RIGHT;
I'm on archlinux using
gtkmm3 version 3.24.5-2
and libgig from svn.
I managed to install gigedit by applying two patches:
gigedit-1.2.0-libdir.patch
gigedit-1.2.0-redeclare.patch
but have no clue, what exactly it is they're doing....
So far, so good.
But when trying to create a new gig -file with a sample and save it, gigedit will crash with:
** (gigedit:23922): ERROR **: 09:46:52.773:
unhandled exception (type unknown) in signal handler
A gig-file is created though and I can load that into linuxsampler, but it wont play.
Opening it in gigedit again will show
Wav Data CRC-32: ffffffff
so my guess is, the crash appears when trying to save the sample data.
I again created a new gig-file and found that, when importing the sample and assigning it to a region, it will already show
Wav Data CRC-32: ffffffff
in gigedit before saving it.
This behavior is confirmed with different samples.
Saving an already existing gig-file after changing it in gigedit however seems to work.
Are those issues related to each other?
- My guess is no.
Does anybody has an idea, what the root-cause might be?
Cheers,
Kolja
|
|
From: Christian S. <sch...@li...> - 2021-11-11 15:41:26
|
On Donnerstag, 11. November 2021 10:44:01 CET Kolja Koch wrote: > Hi all, > > while testing some newly created gig-files I ran into some problems with > gigedit. I think, this might have something to do with my installation of > it. > > When trying to install tha latest gegedit version (1.2.0), running > ./configure > runs alright, but then make will give: > > In file included from builtinpix.cpp:2: > ../compat.h:194:21: error: ‘const Pango::Alignment Pango::ALIGN_LEFT’ > redeclared as different kind of entity 194 | const Alignment ALIGN_LEFT > = Alignment::LEFT; > > | ^~~~~~~~~~ > > In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32, > from /usr/include/gtkmm-3.0/gtkmm/container.h:28, > from /usr/include/gtkmm-3.0/gtkmm/box.h:27, > from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27, > from ../compat.h:134, > from builtinpix.cpp:2: > /usr/include/pangomm-1.4/pangomm/layout.h:77:3: note: previous declaration > ‘Pango::Alignment Pango::ALIGN_LEFT’ 77 | ALIGN_LEFT, > > | ^~~~~~~~~~ > > In file included from builtinpix.cpp:2: > ../compat.h:194:45: error: ‘LEFT’ is not a member of ‘Pango::Alignment’ > 194 | const Alignment ALIGN_LEFT = Alignment::LEFT; > > | ^~~~ > > ../compat.h:195:21: error: ‘const Pango::Alignment Pango::ALIGN_CENTER’ > redeclared as different kind of entity 195 | const Alignment > ALIGN_CENTER = Alignment::CENTER; > > | ^~~~~~~~~~~~ > > In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32, > from /usr/include/gtkmm-3.0/gtkmm/container.h:28, > from /usr/include/gtkmm-3.0/gtkmm/box.h:27, > from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27, > from ../compat.h:134, > from builtinpix.cpp:2: > /usr/include/pangomm-1.4/pangomm/layout.h:78:3: note: previous declaration > ‘Pango::Alignment Pango::ALIGN_CENTER’ 78 | ALIGN_CENTER, > > | ^~~~~~~~~~~~ > > In file included from builtinpix.cpp:2: > ../compat.h:195:47: error: ‘CENTER’ is not a member of ‘Pango::Alignment’ > 195 | const Alignment ALIGN_CENTER = Alignment::CENTER; > > | ^~~~~~ > > ../compat.h:196:21: error: ‘const Pango::Alignment Pango::ALIGN_RIGHT’ > redeclared as different kind of entity 196 | const Alignment > ALIGN_RIGHT = Alignment::RIGHT; > > | ^~~~~~~~~~~ > > In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32, > from /usr/include/gtkmm-3.0/gtkmm/container.h:28, > from /usr/include/gtkmm-3.0/gtkmm/box.h:27, > from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27, > from ../compat.h:134, > from builtinpix.cpp:2: > /usr/include/pangomm-1.4/pangomm/layout.h:79:3: note: previous declaration > ‘Pango::Alignment Pango::ALIGN_RIGHT’ 79 | ALIGN_RIGHT > > | ^~~~~~~~~~~ > > In file included from builtinpix.cpp:2: > ../compat.h:196:46: error: ‘RIGHT’ is not a member of ‘Pango::Alignment’ > 196 | const Alignment ALIGN_RIGHT = Alignment::RIGHT; > > > > I'm on archlinux using > gtkmm3 version 3.24.5-2 > and libgig from svn. Which makes me wonder why I don't get these GTK compiler errors with the same gtk(mm) 3.24.5 version. Are you sure you are compiling against the header files of exactly *that* gtk version and not probably against header files of gtk(mm) 4.x? Because gtk4 is not supported, gtk2 and gtk3 are though. What compiler and compiler version (see config.log file)? > I managed to install gigedit by applying two patches: > > gigedit-1.2.0-libdir.patch > gigedit-1.2.0-redeclare.patch > > but have no clue, what exactly it is they're doing.... Me neither. You are only posting patch names, but not the URL where you got them from. > So far, so good. > But when trying to create a new gig -file with a sample and save it, gigedit > will crash with: > > ** (gigedit:23922): ERROR **: 09:46:52.773: > unhandled exception (type unknown) in signal handler > > A gig-file is created though and I can load that into linuxsampler, but it > wont play. Opening it in gigedit again will show > Wav Data CRC-32: ffffffff > so my guess is, the crash appears when trying to save the sample data. > > I again created a new gig-file and found that, when importing the sample and > assigning it to a region, it will already show Wav Data CRC-32: ffffffff > in gigedit before saving it. The CRC-32 checksum of each sample in a .gig file are generated/updated only at the end of the .gig file saving process. So it is normal that new samples first have a CRC initialized with ffffffff at first. > This behavior is confirmed with different samples. > > Saving an already existing gig-file after changing it in gigedit however > seems to work. > > > Are those issues related to each other? > - My guess is no. > Does anybody has an idea, what the root-cause might be? As my telepathic abilities are just sub average, and my valueable crystal ball has never been handed back to me, I fear you would need to provide more info that a mortal person would be able to decode. You could start by providing the questioned info, plus a backtrace of the crash. > > > Cheers, > Kolja CU Christian |
|
From: Kolja K. <ko...@fr...> - 2021-11-12 11:16:02
|
> Which makes me wonder why I don't get these GTK compiler errors with the same > gtk(mm) 3.24.5 version. Are you sure you are compiling against the header > files of exactly *that* gtk version and not probably against header files of > gtk(mm) 4.x? Because gtk4 is not supported, gtk2 and gtk3 are though. Looks like gtkmm-3.0 to me: configure:20453: g++ -std=gnu++11 -c -g -O2 -I/usr/include/gtkmm-3.0 -I/usr/lib/gtkmm-3.0/include -I/usr/include/giomm-2.4 -I/usr/lib/giomm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/lzo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/at-spi-2.0 -I/usr/include/cairomm-1.0 -I/usr/lib/cairomm-1.0/include -I/usr/include/pangomm-1.4 -I/usr/lib/pangomm-1.4/include -I/usr/include/atkmm-1.6 -I/usr/lib/atkmm-1.6/include -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib/gdkmm-3.0/include -pthread conftest.cpp >&5 GTKMM_LIBS='-lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lgtk-3 -lgdk-3 -lz -latk-1.0 -lcairo-gobject -lgio-2.0 -lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 ' GTK_CFLAGS='-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/lzo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/at-spi-2.0 -pthread ' Or am I missing something? I'm a little bit confused that it states gtkmm-3.0, although my package-management states gtkmm3 version 3.24.5-2 > What compiler and compiler version (see config.log file)? g++ (GCC) 11.1.0 > > I managed to install gigedit by applying two patches: > > > > gigedit-1.2.0-libdir.patch > > gigedit-1.2.0-redeclare.patch > > > > but have no clue, what exactly it is they're doing.... > > Me neither. You are only posting patch names, but not the URL where you got > them from. Since installing gigedit-svn from archlinux' AUR didn't work, I looked into the PKGBUILD of the 'official' package https://archlinux.org/packages/community/x86_64/gigedit/ Here's the link to the corresponding github-directory including the patches: https://github.com/archlinux/svntogit-community/tree/packages/gigedit/trunk The PKGBUILD states: # install shared object to global namespace, so no ld.so.conf is required patch -Np1 -i ../"${pkgname}-1.2.0-libdir.patch" # do not extend the pango namespace (breaks the build) patch -Np1 -i ../"${pkgname}-1.2.0-redeclare.patch" > The CRC-32 checksum of each sample in a .gig file are generated/updated only > at the end of the .gig file saving process. So it is normal that new samples > first have a CRC initialized with ffffffff at first. Ah, ok! > > Are those issues related to each other? > > - My guess is no. > > Does anybody has an idea, what the root-cause might be? > > As my telepathic abilities are just sub average, and my valueable crystal ball > has never been handed back to me, I fear you would need to provide more info > that a mortal person would be able to decode. That's a shame! Maybe, you should have asked the crystal ball, before giving it away, if you will ever get it back? ;) > You could start by providing the questioned info, plus a backtrace of the > crash. I will try to gather some more information next week and follow up on this. Thanks and have a nice weekend! Cheers, Kolja |
|
From: Christian S. <sch...@li...> - 2021-11-12 13:40:19
|
On Freitag, 12. November 2021 12:17:16 CET Kolja Koch wrote: > > Which makes me wonder why I don't get these GTK compiler errors with the > > same gtk(mm) 3.24.5 version. Are you sure you are compiling against the > > header files of exactly *that* gtk version and not probably against > > header files of gtk(mm) 4.x? Because gtk4 is not supported, gtk2 and gtk3 > > are though. > Looks like gtkmm-3.0 to me: > > configure:20453: g++ -std=gnu++11 -c -g -O2 -I/usr/include/gtkmm-3.0 > -I/usr/lib/gtkmm-3.0/include -I/usr/include/giomm-2.4 > -I/usr/lib/giomm-2.4/include -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid > -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include > -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include > -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/fribidi > -I/usr/include/cairo -I/usr/include/lzo -I/usr/include/pixman-1 > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 > -I/usr/include/cloudproviders -I/usr/include/atk-1.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 > -I/usr/lib/dbus-1.0/include -I/usr/include/at-spi-2.0 > -I/usr/include/cairomm-1.0 -I/usr/lib/cairomm-1.0/include > -I/usr/include/pangomm-1.4 -I/usr/lib/pangomm-1.4/include > -I/usr/include/atkmm-1.6 -I/usr/lib/atkmm-1.6/include > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 > -I/usr/lib/gdkmm-3.0/include -pthread conftest.cpp >&5 > > > GTKMM_LIBS='-lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lgtk-3 -lgdk-3 > -lz -latk-1.0 -lcairo-gobject -lgio-2.0 -lpangomm-1.4 -lglibmm-2.4 > -lcairomm-1.0 -lsigc-2.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo > -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 ' > > GTK_CFLAGS='-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/harfbuzz > -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount > -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo > -I/usr/include/lzo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 > -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders > -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -I/usr/include/at-spi-2.0 -pthread ' > > Or am I missing something? > I'm a little bit confused that it states gtkmm-3.0, although my > package-management states gtkmm3 version 3.24.5-2 Ok, that's probably fine, i.e. it was presumably Gtk 3.24.5 as you said before. It is normal for the gtkmm header files being placed into a "gktm-3.0" directory. That seems to be consistent among distros. > > What compiler and compiler version (see config.log file)? > > g++ (GCC) 11.1.0 Ok, then probably not an issue in this case, but good to know. > > > I managed to install gigedit by applying two patches: > > > > > > gigedit-1.2.0-libdir.patch > > > gigedit-1.2.0-redeclare.patch > > > > > > but have no clue, what exactly it is they're doing.... > > > > Me neither. You are only posting patch names, but not the URL where you > > got > > them from. > > Since installing gigedit-svn from archlinux' AUR didn't work, I looked into > the PKGBUILD of the 'official' package > https://archlinux.org/packages/community/x86_64/gigedit/ > Here's the link to the corresponding github-directory including the patches: > https://github.com/archlinux/svntogit-community/tree/packages/gigedit/trunk > > The PKGBUILD states: > > # install shared object to global namespace, so no ld.so.conf is required > patch -Np1 -i ../"${pkgname}-1.2.0-libdir.patch" > # do not extend the pango namespace (breaks the build) > patch -Np1 -i ../"${pkgname}-1.2.0-redeclare.patch" So gigedit-1.2.0-libdir.patch just changes the installation directory for gigedit. Some distros want to have certain libs installed like this: /usr/lib/libname-version/*.so and others like this: /usr/lib/*.so And that patch changes it to the latter. Should not be an issue. The other patch gigedit-1.2.0-redeclare.patch tries to address the compilation error that you get, but it does not really do that correctly. It should rather be addressed in compat.h here instead: #ifndef HAS_PANGOMM_CPP11_ENUMS // new enums introduced in unstable pangomm 2.41.3, but not in stable 2.42 # if PANGOMM_MAJOR_VERSION > 2 || (PANGOMM_MAJOR_VERSION == 2 && ((PANGOMM_MINOR_VERSION == 41 && PANGOMM_MICRO_VERSION >= 3) || PANGOMM_MINOR_VERSION > 42)) # define HAS_PANGOMM_CPP11_ENUMS 1 # else # define HAS_PANGOMM_CPP11_ENUMS 0 # endif #endif What is the exact pangomm version reported to be installed there? Because that pangomm version issue was indeed always a bit fishy. As you can see from the compat.h comment above, they had a weird version scheme (stable vs. unstable pangomm, new features branch vs. maintenance branch). So that's something I should fix here more cleanly on our side. All those things are not likely being related with the crash you got though. > > The CRC-32 checksum of each sample in a .gig file are generated/updated > > only at the end of the .gig file saving process. So it is normal that new > > samples first have a CRC initialized with ffffffff at first. > > Ah, ok! There is also "gigdump --verify foo.gig" from the command line BTW (man gigdump). > > > Are those issues related to each other? > > > - My guess is no. > > > Does anybody has an idea, what the root-cause might be? > > > > As my telepathic abilities are just sub average, and my valueable crystal > > ball has never been handed back to me, I fear you would need to provide > > more info that a mortal person would be able to decode. > > That's a shame! Maybe, you should have asked the crystal ball, before giving > it away, if you will ever get it back? ;) Yes, I clearly failed as a user. > > You could start by providing the questioned info, plus a backtrace of the > > crash. > > I will try to gather some more information next week and follow up on this. > Thanks and have a nice weekend! Sure, thanks, have a good one! CU Christian |
|
From: Kolja K. <ko...@fr...> - 2021-11-14 17:07:42
|
> All those things are not likely being related with the crash you got though. Ok, so I'll split this up into two separated mails then... > The other patch gigedit-1.2.0-redeclare.patch tries to address the compilation > error that you get, but it does not really do that correctly. It should rather > be addressed in compat.h here instead: > > #ifndef HAS_PANGOMM_CPP11_ENUMS > // new enums introduced in unstable pangomm 2.41.3, but not in stable 2.42 > # if PANGOMM_MAJOR_VERSION > 2 || (PANGOMM_MAJOR_VERSION == 2 && > ((PANGOMM_MINOR_VERSION == 41 && PANGOMM_MICRO_VERSION >= 3) || > PANGOMM_MINOR_VERSION > 42)) > # define HAS_PANGOMM_CPP11_ENUMS 1 > # else > # define HAS_PANGOMM_CPP11_ENUMS 0 > # endif > #endif > > What is the exact pangomm version reported to be installed there? Because that > pangomm version issue was indeed always a bit fishy. As you can see from the > compat.h comment above, they had a weird version scheme (stable vs. unstable > pangomm, new features branch vs. maintenance branch). So that's something I > should fix here more cleanly on our side. My package-manager states: Name : pangomm Version : 2.46.1-2 Description : C++ bindings for Pango Architecture : x86_64 URL : https://www.gtkmm.org/ Licenses : LGPL Groups : None Provides : libpangomm-1.4.so=1-64 Does this help you? I reinstalled gigedit from svn using the patch, that does seem to work, though it still crashes when trying to save after inserting a single sample. I'll follow up on that in a separate mail. Cheers, Kolja |
|
From: Kolja K. <ko...@fr...> - 2021-11-14 17:48:54
Attachments:
trace.log
|
> > There is also "gigdump --verify foo.gig" from the command line BTW > (man gigdump). > Good to know, thanks! > > > > You could start by providing the questioned info, plus a backtrace of the > > > crash. > > I've never done that before. Is the attached trace.log what you mean? I really can't tell if this is useful to anyone... Cheers, Kolja |
|
From: Christian S. <sch...@li...> - 2021-11-14 18:06:56
|
On Sonntag, 14. November 2021 18:50:13 CET Kolja Koch wrote: > > There is also "gigdump --verify foo.gig" from the command line BTW > > (man gigdump). > > Good to know, thanks! > > > > > You could start by providing the questioned info, plus a backtrace of > > > > the > > > > crash. > > I've never done that before. Is the attached trace.log what you mean? > I really can't tell if this is useful to anyone... > > Cheers, > Kolja You need to compile libgig and gigedit with debugging symbols turned on for the backtrace to contain the required information like function name, source file line number, function arguments passed, etc.: https://bugs.linuxsampler.org/ If you are installing libgig by some distro/package script then also make sure it does not 'strip' the binaries, otherwise it renders the backtrace output useless again. CU Christian |
|
From: Kolja K. <ko...@fr...> - 2021-11-14 19:44:08
Attachments:
gigedit_trace_all_debug_on_2021_11_14.log
|
> You need to compile libgig and gigedit with debugging symbols turned on for > the backtrace to contain the required information like function name, source > file line number, function arguments passed, etc.: > > https://bugs.linuxsampler.org/ > > If you are installing libgig by some distro/package script then also make sure > it does not 'strip' the binaries, otherwise it renders the backtrace output > useless again. > I (thought I) did that, but only with debug-symbols for gigedit. Now I did the following: - Uninstalled libgig, gigedit, linuxsampler - reinstalled them using the svn-versions from Archlinux AUR: - added 'options=(debug !strip)' to all of them, as of https://wiki.archlinux.org/title/Debugging - libgig: https://aur.archlinux.org/packages/libgig-svn/ - linuxsampler: https://aur.archlinux.org/packages/linuxsampler-svn/ - removed dependencies for Steinberg's VST-SDK (link to http://www.steinberg.net/sdk_downloads/vstsdk366_27_06_2016_build_61.zip seems to be dead, I don't use that anyway) - gigedit: https://aur.archlinux.org/packages/gigedit-svn/ - applied the already mentioned patches Ran gigedit using gdb, loaded one sample, assigned it to one region and saved the gig. It crashed. I then saved the attached 'gigedit_trace_all_debug_on_2021_11_14.log' Looks quite like the other one to me... Next thing I'll do is compile libgig and gigedit as mentioned in your link above. Cheers, Kolja |
|
From: Christian S. <sch...@li...> - 2021-11-14 19:42:55
|
On Sonntag, 14. November 2021 18:09:00 CET Kolja Koch wrote: > > All those things are not likely being related with the crash you got > > though. > Ok, so I'll split this up into two separated mails then... > > > The other patch gigedit-1.2.0-redeclare.patch tries to address the > > compilation error that you get, but it does not really do that correctly. > > It should rather be addressed in compat.h here instead: > > > > #ifndef HAS_PANGOMM_CPP11_ENUMS > > // new enums introduced in unstable pangomm 2.41.3, but not in stable > > 2.42 # if PANGOMM_MAJOR_VERSION > 2 || (PANGOMM_MAJOR_VERSION == 2 && > > ((PANGOMM_MINOR_VERSION == 41 && PANGOMM_MICRO_VERSION >= 3) || > > PANGOMM_MINOR_VERSION > 42)) > > # define HAS_PANGOMM_CPP11_ENUMS 1 > > # else > > # define HAS_PANGOMM_CPP11_ENUMS 0 > > # endif > > #endif > > > > What is the exact pangomm version reported to be installed there? Because > > that pangomm version issue was indeed always a bit fishy. As you can see > > from the compat.h comment above, they had a weird version scheme (stable > > vs. unstable pangomm, new features branch vs. maintenance branch). So > > that's something I should fix here more cleanly on our side. > > My package-manager states: > > Name : pangomm > Version : 2.46.1-2 > Description : C++ bindings for Pango > Architecture : x86_64 > URL : https://www.gtkmm.org/ > Licenses : LGPL > Groups : None > Provides : libpangomm-1.4.so=1-64 > > Does this help you? Ok, I hope I nailed this issue now with latest commit: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4000 > I reinstalled gigedit from svn using the patch, that does seem to work, > though it still crashes when trying to save after inserting a single > sample. I'll follow up on that in a separate mail. Yeah, completely unrelated things. This enum issue did definitely not cause the crash you got there. CU Christian |
|
From: Kolja K. <ko...@fr...> - 2021-11-14 19:59:59
|
> > Ok, I hope I nailed this issue now with latest commit: > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4000 > > Uuuh, so we work in parallel! :) Cool, I just tested it by installing gigedit-svn without any changes to the package: It worked like a charm! Great, thanks a lot! :) Cheers, kolja |
|
From: Kolja K. <ko...@fr...> - 2021-11-14 19:55:24
Attachments:
gigedit_trace_all_debug_on_2021_11_14.log
|
> You need to compile libgig and gigedit with debugging symbols turned on for > the backtrace to contain the required information like function name, source > file line number, function arguments passed, etc.: > > https://bugs.linuxsampler.org/ > > If you are installing libgig by some distro/package script then also make sure > it does not 'strip' the binaries, otherwise it renders the backtrace output > useless again. > I (thought I) did that, but only with debug-symbols for gigedit. Now I did the following: - Uninstalled libgig, gigedit, linuxsampler - reinstalled them using the svn-versions from Archlinux AUR: - added 'options=(debug !strip)' to all of them, as of https://wiki.archlinux.org/title/Debugging - libgig: https://aur.archlinux.org/packages/libgig-svn/ - linuxsampler: https://aur.archlinux.org/packages/linuxsampler-svn/ - removed dependencies for Steinberg's VST-SDK (link to http://www.steinberg.net/sdk_downloads/vstsdk366_27_06_2016_build_61.zip seems to be dead, I don't use that anyway) - gigedit: https://aur.archlinux.org/packages/gigedit-svn/ - applied the already mentioned patches Ran gigedit using gdb, loaded one sample, assigned it to one region and saved the gig. It crashed. I then saved the attached 'gigedit_trace_all_debug_on_2021_11_14.log' Looks quite like the other one to me... Next, I recompiled gigedit manually with CXXFLAGS="-O0 -g3" ./configure && make and ran libtool --mode=execute gdb --arg src/gigedit/gigedit After the crash, I typed bt and got: #0 0x00007ffff631c200 in g_log_structured_array () at /usr/lib/libglib-2.0.so.0 #1 0x00007ffff631c4c6 in g_log_default_handler () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff631d8fd in g_logv () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff631dc00 in g_log () at /usr/lib/libglib-2.0.so.0 #4 0x00007ffff720ba4a in () at /usr/lib/libglibmm-2.4.so.1 #5 0x00007ffff720bce8 in () at /usr/lib/libglibmm-2.4.so.1 #6 0x00007ffff722655c in Glib::IOSource::dispatch(sigc::slot_base*) () at /usr/lib/libglibmm-2.4.so.1 #7 0x00007ffff721f7d7 in Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*) () at /usr/lib/libglibmm-2.4.so.1 #8 0x00007ffff63153e5 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #9 0x00007ffff6369799 in () at /usr/lib/libglib-2.0.so.0 #10 0x00007ffff6314a63 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #11 0x00007ffff6bcd88f in gtk_main () at /usr/lib/libgtk-3.so.0 #12 0x00007ffff7e527ee in GigEdit::run(int, char**) (this=this@entry=0x7fffffffe330, argc=<optimized out>, argc@entry=1, argv=<optimized out>, argv@entry=0x7fffffffe538) at gigedit.cpp:416 #13 0x0000555555555084 in main(int, char**) (argc=1, argv=0x7fffffffe538) at main.cpp:53 Cheers, Kolja |
|
From: Christian S. <sch...@li...> - 2021-11-14 22:10:43
|
On Sonntag, 14. November 2021 20:56:49 CET Kolja Koch wrote: > Ran gigedit using gdb, loaded one sample, assigned it to one region and > saved the gig. It crashed. I then saved the attached > 'gigedit_trace_all_debug_on_2021_11_14.log' > > Looks quite like the other one to me... > > Next, I recompiled gigedit manually with > CXXFLAGS="-O0 -g3" ./configure && make > > and ran > libtool --mode=execute gdb --arg src/gigedit/gigedit > > After the crash, I typed > bt > > and got: > > #0 0x00007ffff631c200 in g_log_structured_array () at > /usr/lib/libglib-2.0.so.0 #1 0x00007ffff631c4c6 in g_log_default_handler > () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff631d8fd in g_logv () at > /usr/lib/libglib-2.0.so.0 > #3 0x00007ffff631dc00 in g_log () at /usr/lib/libglib-2.0.so.0 > #4 0x00007ffff720ba4a in () at /usr/lib/libglibmm-2.4.so.1 > #5 0x00007ffff720bce8 in () at /usr/lib/libglibmm-2.4.so.1 > #6 0x00007ffff722655c in Glib::IOSource::dispatch(sigc::slot_base*) () at > /usr/lib/libglibmm-2.4.so.1 #7 0x00007ffff721f7d7 in > Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*) () at > /usr/lib/libglibmm-2.4.so.1 #8 0x00007ffff63153e5 in > g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #9 > 0x00007ffff6369799 in () at /usr/lib/libglib-2.0.so.0 > #10 0x00007ffff6314a63 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 > #11 0x00007ffff6bcd88f in gtk_main () at /usr/lib/libgtk-3.so.0 > #12 0x00007ffff7e527ee in GigEdit::run(int, char**) > (this=this@entry=0x7fffffffe330, argc=<optimized out>, argc@entry=1, > argv=<optimized out>, argv@entry=0x7fffffffe538) at gigedit.cpp:416 > #13 0x0000555555555084 in main(int, char**) (argc=1, argv=0x7fffffffe538) at > main.cpp:53 So there is not any of our code actually involved in the crash, at least not directly. Could be related to this: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1898082 libglimm was trying to log some message by calling g_log(), and the latter eventually crashed. That's very odd, but it does not look like the bug was anywhere on our side. It appears this is rather a (relatively) new bug in either libglibmm or glib. Would require to recompile those with debugging turned on to learn more. CU Christian |
|
From: Kolja K. <ko...@fr...> - 2021-11-15 09:45:22
|
> So there is not any of our code actually involved in the crash, at least not > directly. Could be related to this: > > https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1898082 > > libglimm was trying to log some message by calling g_log(), and the latter > eventually crashed. That's very odd, but it does not look like the bug was > anywhere on our side. It appears this is rather a (relatively) new bug in > either libglibmm or glib. Would require to recompile those with debugging > turned on to learn more. Ok, thanks for investigating that so far! I took a quick look into that. It currently seems like a dead end for me, since I don't want to fiddle too much with those right now. I'll eventually investigate that issue later on. > There is also "gigdump --verify foo.gig" from the command line BTW > (man gigdump). Thanks again for pointing that out! By using that, I identified some problems with my gig-files that seem to be related to merging mono into stereo-samples. I guess, I'll have to look a little bit deeper into your gig2stereo-code and implement some of your checks and methods from there... Cheers, Kolja |