Hi

This bug is perhaps for Wally who packages Guayadeque, but I wonder if it's a 
Packaging problem ? Upstream bug ?

I have been using Guayadeque for some years without any problem on my main computer (mageia6 mageia7 mageia8) x86_64

I just installed Guyadeque on an old little laptop (Compaq mini 311 with mageia8 i586)  that I use when I travel or navigate (with OpenCPN that I maintain).

When I launch Guayadeque on this i586 system it crashes immediately : core dumped !
(I attached the debug file)

I don't understand why because the same versions of the required rpms are installed on both of the systems

I tried to rebuild Guayadeque with the last git version inside mock and installed it on the i586 system : no change

Before sending the debug file upstream I need to be sure it's not specific to mageia8 i586 (no problem on x86_64) or to my old laptop

It would be useful that someone having a i586 system on an other kind of computer may test guayadeque and verify if it crashes too


Thanks

Hardware: All => i586

Thank you for the report, Philippe.

I am asking around to see whether anybody has 32-bit hardware to try this. Somebody may try a VM, but real hardware is better.

Len: can you please post on QA-discuss? It is dead easy to try.

CC: (none) => lewyssmith, tarazed25, westel

Checked on "Foolishness," my Dell Inspiron 5100, 32-bit P4, 2 GB RAM, Radeon RV200 graphics, 32-bit Xfce system.

Installed guayadeque and dependencies, with no issues. Ran it from the command line using the command "guayadeque" with no options. A window popped up, indicating a crash. The following messages appeared in the terminal:

17:28:52: Created the configuration folder
17:28:52: Created the lyrics folder
17:28:52: Created the collections folder
17:28:52: Created the Radios folder
17:28:52: Created the Jamendo folder
17:28:52: Created the Magnatune folder
17:28:52: Created the Podcasts folder
17:28:52: Created the Layouts folder
17:28:52: Created the default configuration file
17:28:52: Created the default equalizers file
17:28:52: Created the default lyrics sources file
05:28:53 PM: Initialized locale ( en_US )
sh: line 1: addr2line: command not found
05:29:52 PM: A debug report has been generated. It can be found in
	/tmp/guayadeque_dbgrpt-3827-20211208T172853

And includes the following files:
	guayadeque.xml: process context description

Please send this report to the program maintainer, thank you!
Aborted (core dumped)

So, it would appear that the program started, but ran into a script command that it couldn't execute. I'm not a coder by any means, but I suspect a missing dependency.

CC: (none) => andrewsfarm

Created attachment 13028 [details]
TJ's debug report file

My crash also generated a debug report file, probably similar to that of the reporter.

Hi Thomas

Indeed the debug report file you attached is exactly the same as the beginning of mine

But mine ends with some more lines :

<stack>
<frame level="0" function="Guayadeque::guMainApp::OnFatalException()" offset="0" address="0x81a6bc2"/>
<frame level="1" offset="0x1a27b8" address="0xb7e6c7b8" module="/lib/libwx_baseu-3.1.so.5"/>
<frame level="2" function="__kernel_sigreturn" offset="0" address="0xb7f81560" module="linux-gate.so.1"/>
<frame level="3" offset="0x26078" address="0xb6a82078" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="4" offset="0x5d797" address="0xb6ab9797" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="5" offset="0xb02ac" address="0xb6b0c2ac" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="6" offset="0x4b027" address="0xb6aa7027" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="7" offset="0xc071b" address="0xb6b1c71b" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="8" offset="0x138e61" address="0xb6b94e61" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="9" function="wxSQLite3Database::Open(wxString const&, wxMemoryBuffer const&, int)" offset="0x8c" address="0xb6ba8bec" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="10" function="wxSQLite3Database::Open(wxString const&, wxString const&, int)" offset="0x114" address="0xb6ba8fc4" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="11" function="Guayadeque::guDb::Open(wxString const&)" offset="0" address="0x81da999"/>
<frame level="12" function="Guayadeque::guDb::guDb(wxString const&)" offset="0" address="0x81daa4c"/>
<frame level="13" function="Guayadeque::guDbCache::guDbCache(wxString const&)" offset="0" address="0x81dadf5"/>
<frame level="14" function="Guayadeque::guMainApp::OnInit()" offset="0" address="0x81a54c6"/>
<frame level="15" function="wxEntry(int&, wchar_t**)" offset="0x86" address="0xb7db6406" module="/lib/libwx_baseu-3.1.so.5"/>
<frame level="16" function="wxEntry(int&, char**)" offset="0x33" address="0xb7db6eb3" module="/lib/libwx_baseu-3.1.so.5"/>
<frame level="17" function="main" offset="0" address="0x819ac0e"/>
<frame level="18" function="__libc_start_main" offset="0x106" address="0xb65a9e86" module="/lib/libc.so.6"/>
<frame level="19" function="_start" offset="0" address="0x819f521"/>
</stack>
</report>


It seems that there's a problem specific to 32 bits arch : stack overflow ?

Unless someone find a reason specific for the mageia i586 rpm 

I will open an issue on the anonbeat github (he is really fast responsive, and already solved a little problem when building upon wxwidgets 3.1.4 that I reported )

Hi
I just sent an issue report to anonbeat

https://github.com/anonbeat/guayadeque/issues/137

That doesn't prevent to dig on Mageia's side

Perhaps to test with cauldron 32bits installed to verify if the last builds are OK

Thank you TJ for such a rapid confirmation.
And Philippe for raising this upstream.

In the light of "I will open an issue on the anonbeat github (he is really fast responsive", I think we should await this upstream response before passing this to Jani; whom I am CC'ing as advanced warning.

URL: (none) => https://github.com/anonbeat/guayadeque/issues/137
Keywords: (none) => UPSTREAM
CC: tarazed25, westel => jani.valimaa

Hi Lewis

Yes we may await the upstream response... and it may quickly happen :

I have sent a mail to Juan Rios (aka anonbeat) , besides opening a new issue (mails are more quickly read than new issues on github...)

He immediately answered :

<< I will take a look but for what I saw on github it looks like its a wxsqlite problem... but I will try to reproduce the problem. >>

There are not lots of distributions continuing to support 32bits processors, (fortunately Mageia, besides Debian and some Debian forks) and so far not so much users facing this kind of bug ... 
That's certainly why noone rang the bell before !


Nevertheless we may perhaps dig on our side :

Indeed as we can see in the last 20 lines of the attached debug file there seems to be a problem of stack with wxsqlite : 

not enough memory available ? certainly no : guayadeque  occupies only 54 Mbytes 

not enough memory allowed to the stack by the program itself

using multihreading with a one core processor ?

problem of arch (i586 might be not compatible ?)

kernel problem (I tried several i586 kernels leading to the same crash)


Unless this was caused by the use of a snapshot of a prerelease of wxgtk 3.1.5 to build guayadeque and wxsqlite (that would be a Mageia problem and not an upstream one)
This might be tested on Cauldron rebuilding this staff on the final release of wxgtk 3.1.5

Unfortunately I don't have 32 bit HW available or possibility to install 32 bit Mageia to real HW ATM. However I tried i586 guayadeque with Virtualbox and wasn't able to reproduce the crash.

Hi Jani

I think it indeed needs real hardware to be reproduced (like Thomas could do)

Unfortunately there are less and less such hardware users... and less and less distributions for this old kind of hardware (planned obsolescence !)

And maybe it won't be neither possible nor worth digging this for the upstream developper ... nor for the packagers...

One difference between my hardware and the usual VirtualBox install is the "processor" and therefore the kernel that is being used.

My hardware has a P4 processor, an i686, and therefore is supposed to work best with the features of kernel-desktop. The default 32-bit "processor" emulated by Vbox is an i586 processor, and can't function with kernel-desktop. It needs kernel-desktop586.

Usually, this difference means that some 32-bit programs will work on the newer processor, but not the older one. But, it's not hard (at least not for me, someone who isn't a coder) to imagine a case where the reverse could be true, where it could be that the program works with the desktop586 kernel/processor and not the desktop kernel/processor.  

There also have been cases where the 32-bit server kernel worked when the desktop kernel didn't.

I don't know if simply installing the other kernel(s) on my hardware would do the trick, but I can give it a try.

Changing to kernel-desktop586 made no difference.

I knew it was a long shot, but I had to try.

I tried it on a 32-bit install on x86_64 hardware, and it crashed there, too. But as in Comment 9, when I tried it in Vbox, it didn't crash. 

Most strange. Oh, well. On to other things...

(In reply to Thomas Andrews from comment #12)
> Changing to kernel-desktop586 made no difference.
> 
> I knew it was a long shot, but I had to try.

I tried several kernel too (kernel-desktop, kernel-desktop586) before opening this bug
Same crash for all of them

I'm gonna try kernel-server that I forgot to test !

hi

Juan Rios tested on a virtual box with Mageia8 i586 installed : 
He didn't use the rpm but compile itself guayadeque which didn't crash...

same as https://bugs.mageia.org/show_bug.cgi?id=29742#c9 and in https://bugs.mageia.org/show_bug.cgi?id=29742#c12
 
he has no 32bits computer nor real 64bits computer with mageiai586 installed...

On my side :

I tried with kernel-server kernel-desktop kernel-desktop586 
always crash

I'm gonna tried to build on a real 32bits hardware !

I built the rpm on my old 32bits mini computer (it took 2 hours...)
I installed it
Crashes
I attach the debug file

There seems to be a problem with wxgtk3.1 on 32bits hardware

Created attachment 13050 [details]
debug file for guayadeque 0.4.6-7.git20211201.1.mga8 32 bits

debug file for guayadeque built on real 32bits hardware

Thank you for all your work on this.
>There seems to be a problem with wxgtk3.1 on 32bits hardware
My 64-bit system has:

- wxgtk3.0-3.0.5.1-1.mga8
Source RPM  : wxgtk3.0-3.0.5.1-1.mga8.src.rpm

- wxgtk3.1-3.1.5-0.git20201230.1.mga8
Source RPM  : wxgtk-3.1.5-0.git20201230.1.mga8.src.rpm   ? the 3.1 is different

Assigning this to DavidG who has seen both versions.

Source RPM: guayadeque 0.4.6-7.git20201222.2.mga8 => guayadeque 0.4.6-7.git20201222.2.mga8, wxgtk-3.1.5-0.git20201230.1.mga8.src.rpm
Summary: guayadeque crashes on i586 but not on x86_64 => guayadeque crashes on i586 but not on x86_64; wxgtk-3.1 is suspected
Assignee: bugsquad => geiger.david68210
CC: lewyssmith => (none)

Other applications are also affected.

"urmpq --whatrequires-recursive wxgtk3.1" returns a rather long list of packages that depend on it. Included are guayadeque, audacity, and gnuplot.

I installed audacity on both 32-bit and 64-bit systems, and it runs and plays an mp3 file with no problem. I did not try to do any editing with it.

Gnuplot is a different story. I tested gnuplot on Mageia 7 back in March, but didn't do any testing with the then-in-Cauldron Mageia 8. It worked well in Mageia 7, but...

With both arches, the result was the same: You can run gnuplot (or gnuplot-qt), and use a simple command like "plot sin(x)" (as suggested at https://riptutorial.com/gnuplot) and it plots the function with no issues. However, if I go to http://www.gnuplot.info/demo/ and download a more involved demo script, save it in a text file, and then try to run "gnuplot-qt <filename>" from the command line, the plot shows briefly on the screen and then gnuplot crashes back to the terminal.

Removing the UPSTREAM flag, since it now looks like the problem is probably in our packages somewhere. Also changing from i586 to all, because gnuplot appears to be affected on both arches.

Keywords: UPSTREAM => (none)
Hardware: i586 => All

(In reply to Thomas Andrews from comment #19)
> Other applications are also affected.
> 
> "urmpq --whatrequires-recursive wxgtk3.1" returns a rather long list of
> packages that depend on it. Included are guayadeque, audacity, and gnuplot.
> 
you may add opencpn !

Gtk successive versions are not backward compatible :

We had some problem with OpenCPN and its plugins in Mageia8, rebuilt upon gtk3.1 when the prerelease appeared in cauldron for Mageia8 
OpenCPN had been created for gtk3.0... worked well in Mageia7 but crashed in Mageia8, inexplicably : weeks of digging to understand why :

Finally we have had to rebuild them back with a strict BuildRequire gtk3.0 !!!

Back to Guayadeque
Guayadeque built upon gtk3.0 worked perfectly with Mageia7 32bits on my Compaq Mini311

Guayadeque built for Mageia8 64bits with the prerelease of gtk3.1 works well in Mageia8 but Juan Rios its developper had to modify several lines of the code he had created upon gtk3.0 (the packagers wrote to him because they couldn't build Guayadeque anymore in Cauldron for Mageia8)

Guayadeque (built upon the prerelease of gtk 3.1 and simply copied from Mageia8 to Cauldron ) crashed inside Cauldron for Mageia9 when I tested it... and Jani have had to rebuild it upon the final release of gtk 3.1
It works now but sends hundred of warnings about wxwidgets ...
https://bugs.mageia.org/show_bug.cgi?id=29755

Juan Rios is working on this too 

It's really frustrating that something that works perfectly has to be rewritten because the basis programs used to build it are updated without backward compatibility

Crazy rush forward !

Hi everyone

Shame on us ! it's not a guayadeque problem on 32bits systems

Juan Rios and me wrote some mails...
He installed Mageia8 32bits on a virtual machine
installed the rpm
built guayadeque
But encountered no problem

Finally he asked me to build myself guayadeque with his own recipe :
"Can you build it with ./buildd so its built with debug information? That way the crash dump will include some information I can check"

So I cloned his last code on my 32bits Compaq mini
launched a console
cd to the guayadeque folder
enter ./buildd

then sudo install

the app appears in Mageia menu

Launch Guayadeque in a console it works !!!!
(only some gtk warnings about gtk widgets)

Launch Guayadeque from the Mageia menu it works !!!

Something wrong in the spec file ? 
it's not a BS problem nor a mock problem because when I build the rpm on my 32bits system and install it it crashes !

NB To apply Juan'recipe, the same BuildRequires as for building the rpm was installed : no more nor less...

correcting a lapsus 
> 
> So I cloned his last code on my 32bits Compaq mini
> launched a console
> cd to the guayadeque folder
> enter ./buildd
> 
> then sudo install
> 
Read
sudo make install  instead of  sudo install

Filing a new bug on Gnuplot.

(In reply to Thomas Andrews from comment #24)
> Filing a new bug on Gnuplot.

Gnuplot situation was invalid - user error, coming from inexperience.

I uninstalled the guayadeque program created following anonbeat's recipe on my 32bits Compaq mini
( from the guayadeque folder in /home/myname/ : sudo make uninstall ... )


On my 64bits, main computer I tried several times to modify the spec file and 
rebuilt a package in mock mageia8 i586
Whatever I try, the rpm installed on my 32bits Compaq mini crashes 
I uninstalled the rpm 


If I use guayadeque built from source it works perfectly, even with an imported configuration folder to use an external drive mounted with fstab in the same path as the one of my 64bits computer (18 000 audio files)

I can't understand where is the problem when packaging for i586 system

The solution for me is to use the manually built program and not a rpm !!!

This seems to be not so easy to debug the packaging and test without having a real 32 bits system... 
It's out of my limited skill

Try to build from sources with our build time flags. You can see them with
$ rpm --eval %set_build_flags

Then copy paste the lines to buildd scriptlet.

Created attachment 13053 [details]
buildd script for guayadeque

Hi Jani

I was not sure where to add the mageia's flags
I added them at the end of the buildd script (after the && make (2) line )

have a glance at buildd-modified : next attached file

Created attachment 13054 [details]
modified buildd script

Here is the modified buildd script used to build from source inside the real 32 bits hardware which could build a working guayadeque with the simple build script

It will take 1 or 2 hours to build and test


Besides this in the spec file for Mageia there are 2 useless files now:

# remove bundled libs
rm -rf src/wx/wxsql* src/wxsqlite3

since there is no more bundled source of wxsqlite3

Hi again Jani

OK 
I built guayadeque with the buildd-modified script

No problem to build (except a warning about a missing dependency : libindicate that is useless out of ubuntu)

I installed it
it works

Unless I added the mageia flags in the wrong place, adding them doesn't change anything when building and installing the program from source (not packaging!!!)

(In reply to Philippe Didier from comment #30)
> 
> Unless I added the mageia flags in the wrong place, adding them doesn't
> change anything when building and installing the program from source (not
> packaging!!!)

Build flags should be set, of course, before the build. Add them before cmake call.

(In reply to Jani Välimaa from comment #31)
> (In reply to Philippe Didier from comment #30)
> > 
> > Unless I added the mageia flags in the wrong place, adding them doesn't
> > change anything when building and installing the program from source (not
> > packaging!!!)
> 
> Build flags should be set, of course, before the build. Add them before
> cmake call.

Sorry
I didn't know where to insert this
(I have still a lot to learn)

I'm gonna do this in the right way 
But this will take 1 or 2 hours, unless the build process aborts

Hi 

I rebuilt inserting the build flags in the right place inside the buildd script

I installed the program and it crashed immediately when launched
the debug file is the same as the first attached

It seems there's a stack overflow

The problem comes perhaps from this : -fstack-protector --param=ssp-buffer-size=4

My processor is an intel Atom n270
(https://ark.intel.com/content/www/fr/fr/ark/products/36331/intel-atom-processor-n270-512k-cache-1-60-ghz-533-mhz-fsb.html)

That may explain why 
a simple build gives a working program 
when the rpm (or the build with mageia build flags) gives a crashing program.


The Mageia macros are OK for more recent processors but not for such old as mine .

Hi Jani

The bug appears apparently only on real old 32 bits hardware (not inside virtualbox with mageiai586), like for Thomas Andrews and me, with the rpm built with Mageia build flags.

It's not strictly a guayadeque bug and absolutely not an upstream bug since simply build from source it'OK

It seems to be a Mageia packaging problem concerning only old real i586 hardware...

Is there a way to add something in the spec so that these build flags are not used for i586 but only for 64bits :

%ifarch i586
blabla = 0
%else
blabla = 1
%endif

Unless this impact more recent hardware that afford those build flags


With a wider look : are there other packaged programs crashing on real i586 hardware with such stack problems ?
Does it need to create a conditional build_flags depending on arch

(In reply to Philippe Didier from comment #34)
> Hi Jani
> 
> The bug appears apparently only on real old 32 bits hardware (not inside
> virtualbox with mageiai586), like for Thomas Andrews and me, with the rpm
> built with Mageia build flags.
> 
> It's not strictly a guayadeque bug and absolutely not an upstream bug since
> simply build from source it'OK
> 
> It seems to be a Mageia packaging problem concerning only old real i586
> hardware...

A bit of a correction, Phillipe. Please see Comment 13. I tried guayadeque on a 32-bit install on 64-bit hardware, and it crashed. 

Specifically, the hardware is as follows: AMD Phenom II X4 910, ASRock A790GXH/128M motherboard, 8GB DDR2 RAM, AMD HD 8490 graphics card, and it shouldn't matter, but Atheros AR92BX wifi card. The install is a Plasma system, installed using netinstall at the time, and is using the i586 server kernel. \

Same hardware, only with a 64-bit Plasma install, and it did NOT crash.

Thanks Thomas for this correction

So that means that a 32-bits install on real hardware induces crashes of packaged guayadeque (even on your 64bits hardware)
when a 32-bits install inside a virtualbox doesn't ! (even on your 64bits hardware where a real install induces a crash !!!?)

I may add that the crash happens whatever kernel is used on my real hardware (Compaq mini311) with a 32bits install (I tried kernel-desktop, kernel-desktop586, kernel-server, with several versions) 

That may mean too that a virtualbox doesn't plainly function like real hardware !
and that the way a virtualbox functions depends on the hardware used to test :
Jani didn't get a crash on his hardware, 
Juan Rios (aka anonbeat the Guayadeque developper) told me that he didn't get a crash with Mageia 586 installed inside a virtualbox on his hardware, 
when you got a crash inside the virtualbox on your own hardware

It's more and more complex to understand... and it seems that a virtual machine doesn't help to debug !

The only track that I found is that wxsqlite apparently induces a stack overflow when guayadeque is built with the Mageia's build flags for a 32bits system

Sorry, (English is not my natural language)  in my previous comment these sentences were not clear :
> 
> That may mean too that a virtualbox doesn't plainly function like real
> hardware !
> and that the way a virtualbox functions depends on the hardware used to test
> :
> Jani didn't get a crash on his hardware, 
> Juan Rios (aka anonbeat the Guayadeque developper) told me that he didn't
> get a crash with Mageia 586 installed inside a virtualbox on his hardware, 
> when you got a crash inside the virtualbox on your own hardware
> 

It's clearer written this way

That may mean that a 32bits install inside a virtualbox doesn't plainly function like a 32bits install on a real hardware ! (bad news for testing...)

- Jani didn't get a crash inside a virtualbox on his hardware, 
- Juan Rios (aka anonbeat the Guayadeque developper) told me that he didn't
get a crash with Mageia 586 installed inside a virtualbox on his hardware, 
- Thomas got no crash inside a virtualbox on his own hardware, where a real install of 32bits version of Mageia caused the crash

Besides this a real install of Mageia 586 on the hardware induces a crash whatever the processor is (32bits like mine, 64bits like Thomas'one), and whatever the kernel we use (kernel-desktop, kernel-desktop586, kernel-server) 


Maybe some other programs satisfying the test inside a virtualbox will crash on a real 32bits install... 
That would create a problem to reproduce some reported bugs for the QA, or the bugsquad or the maintainers, if they can't use some hardware with a real 32bits install.
Fortunately Thomas could, confirming the bug this way, and encouraging to dig to understand where this bug comes from.

The crash only happens in my i586 vb guest if the following packages are
installed.
(medium "Core Updates Testing (distrib5)")
  libwx_baseu3.1_5               3.1.5        1.mga8        i586    
  libwx_baseu_xml3.1_5           3.1.5        1.mga8        i586    
  libwx_gtk3u_aui3.1_5           3.1.5        1.mga8        i586    
  libwx_gtk3u_core3.1_5          3.1.5        1.mga8        i586    
  libwx_gtk3u_html3.1_5          3.1.5        1.mga8        i586    
  libwx_gtk3u_qa3.1_5            3.1.5        1.mga8        i586    
  wxgtk3.1                       3.1.5        1.mga8        i586

With the core release version of those packages it works.

On my x86-64 host with those packages installed, it crashes too ...
$ guayadeque 
guayadeque: symbol lookup error: /lib64/libwx_gtk3u_qa-3.1.so.5: undefined symbol: _ZN19wxTopLevelWindowGTK10SetMinSizeERK6wxSize, version WXU_3.1

CC: (none) => davidwhodgins

(In reply to Dave Hodgins from comment #38)
> The crash only happens in my i586 vb guest if the following packages are
> installed.
> (medium "Core Updates Testing (distrib5)")
>   libwx_baseu3.1_5               3.1.5        1.mga8        i586    
>   libwx_baseu_xml3.1_5           3.1.5        1.mga8        i586    
>   libwx_gtk3u_aui3.1_5           3.1.5        1.mga8        i586    
>   libwx_gtk3u_core3.1_5          3.1.5        1.mga8        i586    
>   libwx_gtk3u_html3.1_5          3.1.5        1.mga8        i586    
>   libwx_gtk3u_qa3.1_5            3.1.5        1.mga8        i586    
>   wxgtk3.1                       3.1.5        1.mga8        i586
> 
> With the core release version of those packages it works.
> 
> On my x86-64 host with those packages installed, it crashes too ...
> $ guayadeque 
> guayadeque: symbol lookup error: /lib64/libwx_gtk3u_qa-3.1.so.5: undefined
> symbol: _ZN19wxTopLevelWindowGTK10SetMinSizeERK6wxSize, version WXU_3.1

On my 32 bits system the Core Updates Testing repo is not activated
So there are only the prerelease of those libs from Core Repo (3.1.5-0.git20201230.1.mga8) upon which guayadeque was built

In a vb guest you might not use a version of wxgtk different from what was used to build the guayadeque package, or other packages depending of those libs... 
You might get bad surprises in your vb with other packages...
If you use the testing repo you should have to rebuild the Guayadeque rpm to be complient with those new versions


With Mageia 64 bits installed on your hardware, you will certainly obtain a crash if you activate the testing repos and install :
  lib64wx_baseu3.1_5               3.1.5        1.mga8       x86_64
  lib64wx_baseu_xml3.1_5           3.1.5        1.mga8       x86_64
  lib64wx_gtk3u_aui3.1_5           3.1.5        1.mga8       x86_64
  lib64wx_gtk3u_core3.1_5          3.1.5        1.mga8       x86_64
  lib64wx_gtk3u_html3.1_5          3.1.5        1.mga8       x86_64
  lib64wx_gtk3u_qa3.1_5            3.1.5        1.mga8       x86_64
  wxgtk3.1                         3.1.5        1.mga8       x86_64

Each version of those libs are not backward compatible and a rebuild is needed for packages depending on them...
You might get crashes with guayadeque and with other packages depending of wxgtk !



The problem I encountered is not caused by a problem of libwx or wxgtk version 
but apparently caused by the rpm build_flags since I experienced that :

- with a rpm built on my 32bits computer (updated but without Core Updates Testing repo being activated) when I install and launch it I get a crash whichever git clone of Guayadeque I use : 
guayadeque-0.4.6-7.git20201222.2 or guayadeque-0.4.6-8.git20211201.1

- with this program simply built from each of those 2 git clones 
with ./build & sudo make install 
I get no crash

NB to be sure not to have artifacts I didn't build my rpms inside mock on my 64bits computer but on my old 32 bits computer (it took 2 hours each time) :
Debugging takes time sometimes ! 
;-)

From https://bugs.mageia.org/show_bug.cgi?id=29848#c40

"There's no solution for this since we can't prevent the use of the build time flags when building a rpm for Mageia"

If that's the case, then we should close this bug as a "Won't Fix." 

Moreover, we should seriously consider not offering a 32-bit version of guayadeque in Mageia 9 and beyond. And if that's not possible, then perhaps we should consider dropping it altogether.

The fact that a user can make it work if he has sufficient skills is not enough. We should not offer an rpm that we know won't work.

Hi Thomas

I don't think Guayadeque should be simply dropped : it works perfectly on a 64bits system

The problem occurs only with the 32bits rpm on old 32bits i586 hardware (not inside a virtualbox !) : guayadeque segfaults

This is a wilder problem about rpm building for i586 without sse sse2 or mmx
(you may have a glance at this thread in gmane.linux.mageia.devel  : 
32bit i586 and SSE/SSE2 instructions slipping )

It seems that Mageia9 will no more have rpms built for such old hardware
But Mageia8 intended to work on this ...

I wonder if there is a way to modify the guayadeque spec so that the rpm build flags are not applied for this particular program
https://bugs.mageia.org/show_bug.cgi?id=29742#c34

Unless the decision is taken of building rpms strictly for i686 and no more for i586 !
(maybe other programs will be concerned )
In this case this needs a warning for the users
(Mageia with Debian were two of the last rare distribution supporting 32bits hardware)

Planned obsolescence !!!

(In reply to Philippe Didier from comment #41)
> Hi Thomas
> 
> I don't think Guayadeque should be simply dropped : it works perfectly on a
> 64bits system
> 
> The problem occurs only with the 32bits rpm on old 32bits i586 hardware (not
> inside a virtualbox !) : guayadeque segfaults
> 
> This is a wilder problem about rpm building for i586 without sse sse2 or mmx
> (you may have a glance at this thread in gmane.linux.mageia.devel  : 
> 32bit i586 and SSE/SSE2 instructions slipping )
> 
> It seems that Mageia9 will no more have rpms built for such old hardware
> But Mageia8 intended to work on this ...
> 
> I wonder if there is a way to modify the guayadeque spec so that the rpm
> build flags are not applied for this particular program
> https://bugs.mageia.org/show_bug.cgi?id=29742#c34
> 
> Unless the decision is taken of building rpms strictly for i686 and no more
> for i586 !
> (maybe other programs will be concerned )
> In this case this needs a warning for the users
> (Mageia with Debian were two of the last rare distribution supporting 32bits
> hardware)
> 
> Planned obsolescence !!!

Except that in this particular case, that doesn't apply. 

The 32-bit CPU in Comment 3 is a P4, which IS i686 hardware, and supports sse, sse2, and mmx. And, it is using the desktop kernel, not the less-able desktop586 kernel that is designed for that older, less-capable hardware.

Also, the CPU in Comment 13 is a Phenom II X4 910, and is using the server kernel, which certainly supports any i686 capabilities. I tested the new build of guayadeque on a real 32-bit install on that hardware, NOT in VirtualBox, and it failed.

 So, it's not just older 32-bit hardware that's failing. It's our 32-bit build that is, for some other reason. A simple warning that the 32-bit version might not work on SOME hardware won't cut it. From what I've seen, it doesn't work on ANY real hardware.

I am setting this to depend on wxgtk3.1 update as I think we should let that out first (including updated Guayadeque even if it still fail often on 32 bit)

CC: (none) => fri
Depends on: (none) => 29848

Hi Morgan

We may say that this doesn't depends on 
https://bugs.mageia.org/show_bug.cgi?id=29748  !

the Mageia8 i586rpm of Guayadeque from Core Repo (built with the prerelease of wxgtk)
already crashed on some 32 bits hardwares when it was OK for 64bits

This is not at all linked to wxgtk but only a consequence of the rpm build flags used after Mageia7 

You may remove this depending link since guayadeque works perfectly on 64bits, as it did before, after having been rebuilt in Updates-Testing upon wgtk 3.1.5 final release 
if you update all the wxgtk stuff in the same time

When the rpm from updates-testing is built for i586 it crashes the same way as before : no change

this 29742 bug is stricly a "rpm build flags" bug

I know this is a separate issue :)

Just intended to note to remember not to ship to updates a new Guayadeque compiled with new wxgtk3.1, before new wxgtk3.1 is released.

resolved by bug 32550

Status: NEW => RESOLVED
Resolution: (none) => FIXED