[Debian GNUstep maintainers] Transition underway
Yavor Doganov
yavor at gnu.org
Tue Jan 15 09:40:28 GMT 2019
On Sun, 13 Jan 2019 00:22:44 +0200,
Yavor Doganov wrote:
> This is the first transition where co-installation of different
> GNUstep core library versions is possible. I knew this would lead to
> some breakage (because the -runtime packages are now providing
> binaries only built for the newest versions), it will be fixed as soon
> as the reverse dependencies are binNMUed.
>
> I'll test all rdeps in this state (before the binNMUs) so that we are
> aware which packages are broken
Most apps are fine, but there are some notable exceptions.
Cenon starts but when you try to create a new document it dies with
SIGBUS:
Program received signal SIGBUS, Bus error.
0x00007ffff7cc74fa in -[NSView removeSubview:] (self=0x5555572f0bd0,
_cmd=<optimized out>, aView=0x4120000041200000) at NSView.m:957
957 NSView.m: Няма такъв файл или директория.
(gdb) bt
#0 0x00007ffff7cc74fa in -[NSView removeSubview:]
(self=0x5555572f0bd0, _cmd=<optimized out>, aView=0x4120000041200000)
at NSView.m:957
#1 0x00007fffed13e361 in -[NSScrollView(GSPrivate) _synchronizeHeaderAndCornerView] (self=0x5555572f0bd0, _cmd=<optimized out>) at NSScrollView.m:1868
#2 0x00007ffff7c6b8ef in -[NSScrollView tile]
(self=0x5555572f0bd0, _cmd=<optimized out>) at NSScrollView.m:1143
#3 0x00005555556daee2 in -[TileScrollView tile]
(self=0x5555572f0bd0, _cmd=<optimized out>) at TileScrollView.m:273
#4 0x00005555556d9ada in -[TileScrollView setDocumentView:]
(self=0x5555572f0bd0, _cmd=<optimized out>, aView=0x5555561178c0)
at TileScrollView.m:260
#5 0x00005555556d85aa in -[Document initWindow]
(self=0x555556117760, _cmd=<optimized out>) at Document.m:220
#6 0x00005555556d0258 in +[Document new]
(self=<optimized out>, _cmd=<optimized out>) at Document.m:182
#7 0x000055555568e243 in -[App new:]
(self=0x555555f2f5e0, _cmd=<optimized out>, sender=<optimized out>)
at App.m:475
#8 0x00007ffff7b5d682 in -[NSApplication sendAction:to:from:]
(self=self at entry=0x555555f2f5e0, _cmd=_cmd at entry=0x7ffff7e99f50 <_OBJC_SELECTOR_TABLE+2768>, aSelector=aSelector at entry=0x555555d0a150, aTarget=0x555555f2f5e0, sender=sender at entry=0x5555572c4a30) at NSApplication.m:2249
(gdb) p aView
$1 = (NSView *) 0x4120000041200000
(gdb) po aView
Cannot access memory at address 0x4120000041200000
Initially I thought it's a GUI bug but I'm confident that's not the
case. Cenon loads the GSCUPS bundle (from gnustep-gui-runtime, linked
against -gui/0.27) and here something really goes wrong.
Valgrind output shows:
--12788-- WARNING: Serious error when reading debug info
--12788-- When reading debug info from /usr/lib/GNUstep/Bundles/GSPrinting/GSCUPS.bundle/GSCUPS:
--12788-- debuginfo section duplicates a section in the main ELF file
==12788== Invalid write of size 8
==12788== at 0x4BF74FA: _i_NSView__removeSubview_ (NSView.m:957)
==12788== by 0x14843360: _i_NSScrollView_GSPrivate__synchronizeHeaderAndCornerView (NSScrollView.m:1868)
==12788== by 0x4B9B8EE: _i_NSScrollView__tile (NSScrollView.m:1143)
==12788== by 0x28EEE1: _i_TileScrollView__tile (TileScrollView.m:273)
==12788== by 0x28DAD9: _i_TileScrollView__setDocumentView_ (TileScrollView.m:260)
==12788== by 0x28C5A9: _i_Document__initWindow (Document.m:220)
==12788== by 0x284257: _c_Document__new (Document.m:182)
==12788== by 0x242242: _i_App__new_ (App.m:475)
==12788== by 0x4A8D681: _i_NSApplication__sendAction_to_from_ (NSApplication.m:2249)
==12788== by 0x4B475E3: _i_NSMenu__performActionForItemAtIndex_ (NSMenu.m:1373)
==12788== by 0x4B4D76D: _i_NSMenuView__performActionWithHighlightingForItemAtIndex_ (NSMenuView.m:1490)
==12788== by 0x4B47379: _i_NSMenu__performKeyEquivalent_ (NSMenu.m:1335)
==12788== Address 0x4120000041200080 is not stack'd, malloc'd or (recently) free'd
==12788== Process terminating with default action of signal 11 (SIGSEGV)
TextEdit has exactly the same problem but it happens on startup.
That's because printing is initialized on startup. Ink works as long
as you don't select "Print..." from the menu which naturally loads the
bundle. So my guess is that any functionality that leads to loading
of the printing bundles is lethal for the application.
Gorm starts and appears to work but not if you try to open a .gorm
file:
2019-01-15 09:56:46.901 Gorm[12821:12821] Exception occurred while loading model: methodForSelector: null selector given
2019-01-15 09:56:46.901 Gorm[12821:12821] Failed to load Gorm
Gorm: NSThread.m:717: GSCurrentThread: Assertion `nil != thr && "No main thread"' failed.
Breakpoint 1, -[NSException raise] (self=0x555556c85120,
_cmd=0x7ffff76e4000 <_OBJC_SELECTOR_TABLE+384>) at NSException.m:1137
1137 NSException.m: Няма такъв файл или директория.
(gdb) bt
#0 0x00007ffff73e47b0 in -[NSException raise]
(self=0x555556c85120, _cmd=0x7ffff76e4000 <_OBJC_SELECTOR_TABLE+384>)
at NSException.m:1137
#1 0x00007ffff73e4413 in +[NSException raise:format:]
(self=self at entry=0x7ffff76e4300 <_OBJC_Class_NSException>, _cmd=_cmd at entry=0x7ffff7712b00 <_OBJC_SELECTOR_TABLE+64>, name=0x7ffff76e4970 <_OBJC_INSTANCE_4>, format=format at entry=0x7ffff77142b0 <_OBJC_INSTANCE_8.13104>)
at NSException.m:1016
#2 0x00007ffff74391af in -[NSObject methodForSelector:]
(self=0x555557dc6790, _cmd=0x7fffec9116d0 <_OBJC_SELECTOR_TABLE+368>, aSelector=0x0) at NSObject.m:1555
#3 0x00007fffec6701ad in -[NSUnarchiver(GNUstep) resetUnarchiverWithData:atIndex:]
(self=0x5555558951b0, _cmd=<optimized out>, anObject=<optimized out>, pos=0)
at NSUnarchiver.m:1741
#4 0x00007ffff74adfe0 in -[NSUnarchiver initForReadingWithData:]
(self=0x5555558951b0, _cmd=<optimized out>, anObject=0x555557dc6790)
at NSUnarchiver.m:529
#5 0x00007fffecc44c05 in -[GormGormWrapperLoader loadFileWrapper:withDocument:] (self=0x5555568c5e00, _cmd=<optimized out>, wrapper=<optimized out>, doc=<optimized out>) at GormGormWrapperLoader.m:432
This is meaningless too, the real culprit is that Gorm loads the
Sndfile and AudioOutput bundles; just like the GSCUPS bundle there is
some corruption and things break.
Lynkeos fails to start (SIGABRT):
2019-01-15 10:11:34.621 Lynkeos[12943:12943] empty components sent
2019-01-15 10:11:34.738 Lynkeos[12943:12943] File NSConcreteHashTable.m: 370. In NSEnumerateHashTable Null table argument supplied
2019-01-15 10:11:34.741 Lynkeos[12943:12943] File NSConcreteMapTable.m: 584. In NSMapGet Null table argument supplied
...repeated multiple times...
2019-01-15 10:11:44.915 Lynkeos[12943:12943] Error Occurred While Updating Menu Edit: <NSException: 0x19eace50> NAME:NSInternalInconsistencyException REASON:unable to contact GDNC server -
please check that the gdnc process is running.
I attempted to start it at '/usr/bin/gdnc'
INFO:(null)
Of course gdnc is running. Log continues:
2019-01-15 10:11:47.876 Lynkeos[12943:12943] Exception occurred while loading model: GSTextStorage(instance) does not recognize insertionPointRectForCharacterIndex:inTextContainer:
2019-01-15 10:11:47.880 Lynkeos[12943:12943] Failed to load Xib
Awkward stuff, but further investigation shows that here the problem
is loading the sound bundles (the app does this unconditionally at
startup as sounds are used as notifications to mark the end of the
image processing).
Paje died with SIGSEGV the first time I tried it but I could not
reproduce then. It loads the ColorPickers bundles, could be related.
Or not.
Pikopixel crashes reliably in the same manner as Paje, the last
message is the same for both apps:
2019-01-15 10:41:07.283 PikoPixel[16900:16900] Wrong number of cells (4) in row insert in matrix
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e04240 in _OBJC_Class_NSActionCell ()
from /usr/lib/libgnustep-gui.so.0.26
(gdb) bt
#0 0x00007ffff7e04240 in _OBJC_Class_NSActionCell ()
at /usr/lib/libgnustep-gui.so.0.26
#1 0x00007fffed0bc37e in -[NSMatrix(PrivateMethods) _renewRows:columns:rowSpace:colSpace:]
(self=0x5555558f16c0, _cmd=<optimized out>, row=1, col=<optimized out>, rowSpace=4, colSpace=0) at NSMatrix.m:4075
#2 0x00007ffff7c10d80 in -[NSMatrix insertRow:withCells:]
(self=0x5555558f16c0, _cmd=<optimized out>, row=4, cellArray=0x5555559fe760) at NSMatrix.m:619
#3 0x00007fffed484258 in -[GSStandardColorPicker loadViews]
(self=0x555555bfaf70, _cmd=<optimized out>) at GSStandardColorPicker.m:202
#4 0x00007fffed4833a8 in -[GSStandardColorPicker provideNewView:]
(self=0x555555bfaf70, _cmd=<optimized out>, initialRequest=<optimized out>)
at GSStandardColorPicker.m:142
#5 0x00007ffff7bb11d8 in -[NSColorPanel(PrivateMethods) _loadPickerAtPath:]
(self=0x555556a9c740, _cmd=<optimized out>, path=0x5555568f8c10)
at NSColorPanel.m:145
#6 0x00007ffff7bb0fe7 in -[NSColorPanel(PrivateMethods) _loadPickers]
(self=0x555556a9c740, _cmd=<optimized out>) at NSColorPanel.m:117
#7 0x00007ffff7bb083b in -[NSColorPanel init]
(self=0x555556a9c740, _cmd=<optimized out>) at NSColorPanel.m:530
Happens right after loading the StanardPicker bundle.
TimeMon behaved in the same manner like Paje: it crashed the first
time but I could not reproduce in subsequent tries. It loads the
RTFConverter bundle.
SimpleAgenda aborts:
2019-01-15 10:53:58.363 SimpleAgenda[19431:19431] Alarms are enabled
2019-01-15 10:53:58.363 SimpleAgenda[19431:19431] File NSConcreteMapTable.m: 584. In NSMapGet Null table argument supplied
2019-01-15 10:53:58.364 SimpleAgenda[19431:19431] Problem posting notification: <NSException: 0x557d7b173ad0> NAME:NSInvalidArgumentException REASON:Attempt to place key-value in null table INFO:(null)
SimpleAgenda: NSThread.m:717: GSCurrentThread: Assertion `nil != thr && "No main thread"' failed.
Breakpoint 1, -[NSException raise] (self=0x555555b55a80,
_cmd=0x7ffff735f000 <_OBJC_SELECTOR_TABLE+384>) at NSException.m:1137
1137 NSException.m: Няма такъв файл или директория.
(gdb) bt
#0 0x00007ffff705f7b0 in -[NSException raise]
(self=0x555555b55a80, _cmd=0x7ffff735f000 <_OBJC_SELECTOR_TABLE+384>)
at NSException.m:1137
#1 0x00007ffff705f413 in +[NSException raise:format:]
(self=0x7ffff735f300 <_OBJC_Class_NSException>, _cmd=<optimized out>, name=0x7ffff735f970 <_OBJC_INSTANCE_4>, format=0x7ffff7346960 <_OBJC_INSTANCE_8.12064>) at NSException.m:1016
#2 0x00007ffff701a4f1 in NSMapInsert
(table=0x0, key=0x7ffff78bb140 <_OBJC_Class_NSFramework_Addresses>, value=0x5555557c3040) at NSConcreteMapTable.m:619
#3 0x00007fffec74af73 in +[NSBundle(Private) _addFrameworkFromClass:]
(self=<optimized out>, _cmd=<optimized out>, frameworkClass=0x7ffff78bb140 <_OBJC_Class_NSFramework_Addresses>) at NSBundle.m:870
#4 0x00007fffec747c10 in +[NSBundle(Private) _addFrameworks]
(self=0x7ffff7337c40 <_OBJC_Class_NSBundle>, _cmd=<optimized out>)
at NSBundle.m:953
#5 0x00007ffff6ff8df5 in +[NSBundle bundleForClass:]
(self=self at entry=0x7ffff7337c40 <_OBJC_Class_NSBundle>, _cmd=_cmd at entry=0x7ffff7e2bd90 <_OBJC_SELECTOR_TABLE+112>, aClass=<optimized out>)
at NSBundle.m:1596
#6 0x00007ffff7b8ec60 in +[NSBundle(NSBundleAdditions) loadNibNamed:owner:]
(self=0x7ffff7337c40 <_OBJC_Class_NSBundle>, _cmd=<optimized out>, aNibName=0x5555555e71d0 <_OBJC_INSTANCE_0.39631>, owner=0x555555845140)
at NSBundleAdditions.m:83
#7 0x00005555555a6ee6 in -[PreferencesController init]
(self=0x555555845140, _cmd=<optimized out>) at PreferencesController.m:15
Doesn't tell much, the exception occurs when it's loading its own
Preferences.gorm. I guess the problem is once again due to loading of
GUI's sound bundles.
GWorkspace aborts with
GWorkspace: NSThread.m:717: GSCurrentThread: Assertion `nil != thr && "No main thread"' failed.
2019-01-15 11:12:11.624 fswatcher[19583:19583] Connection became invalid
Didn't investigate further, I was 100% sure that this one would be broken.
> and see if we can avoid it somehow in the future (or switch back to
> the tight versioning if the breakage is severe and affects many
> and/or important packages). I'm sure some of these problems are
> unavoidable and it's just a matter of weighing up the pros & cons;
> IOW -- whether partial upgrades are worth or not.
IMHO this experiment failed as there is too much breakage and too
many packages involved (including a core one like GWorkspace and an
important one like Gorm). The binNMUs can take quite some time on the
slow architectures (or even fast ones that have huge backlog, like
powerpc/ppc64 now) so we must ensure that no upgrades happen before
the rebuilds are done and that the whole GNUstep stack is upgraded
together and migrates to testing simultaneously.
I expect that the breakage may affect even more apps if the
incompatibility between the two different library versions is more
severe (for example, a new version of the DO protocol).
Additionally, several packages were misbuilt (lusernet.app) or failed
to build (gnustep-sqlclient, sogo) on some architectures as both
library versions were installed in the chroots. That's only because
of the loose dependencies.
In conclusion, I think we can say that two GNUstep library versions
cannot coexist peacefully and partial upgrades (while being a good
thing in general) cause more harm than good. So I propose to tighten
up the dependencies again, to ensure that further transitions do not
expose these problems. What do people think?
> For now, once the binNMUs get flowing in, we should concentrate in
> releasing buster with a GNUstep stack that is as bug-free as possible.
> Please test as many apps as possible and report problems to the BTS
> with the appropriate severity.
This stands. Could someone please confirm that the broken apps above
work if you upgrade and install the binNMUed packages? (I'll refrain
from upgrading for the moment so that I can investigate further.)
More information about the pkg-GNUstep-maintainers
mailing list