Dear Maintainer,
just tried to have a look at the part where steal-ctty is crashing.
It looks like it may get called from [1].
81 # Run the startup scripts once, using the preferred console
82 cons=$(cat /var/run/console-preferred)
83 # Some other session may have that console as
Dear Maintainer,
> (On exit is another issue with the FILE structure
> in readline library, but saw it just on exit.)
I tried to follow why this crash on exit happens,
and found that this second issue is because aeolus
does a "fclose (stdin);" on purpose.
But libreadline is not prepared to that
Control: tags -1 + upstream patch
Dear Maintainer,
Looking at crashes of random bugs I found that this
issue manifests at least at i386 too.
The issue seems to be a too right stack size for a
reader thread.
With doubling the stack size for this thread the
application crashes not at startup
Hello Jeffrey Hundstad,
sorry, I forget to mention that it would help with the
backtrace if the debug symbols would be installed.
For jobs.cgi I assume this would be cups-dbgsym.
These packages are in a separate repository.
Details are about it are in this page:
Hello Jeffrey Hundstad,
just looking at some crashes in some random packages,
I just tried to reproduce this issue inside a minimal qemu VM.
But hit just the line "Couldn't open...", not the segfault.
Also with a simple test printer configured and a test page job.
If it is possible you could
Hello
the issue you observed might be already reported in:
https://bugs.debian.org/924925
Kind regards,
Bernhard
Hello David,
that was not the link I sent in my mail,
I sent a plain link to bugs.debian.org.
Maybe you are viewing my mail via google webmail client,
and that is adding something unwanted?
Kind regards,
Bernhard
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-77017
Dear Maintainer,
I created an upstream bug report and forward this bug to it.
Kind regards,
Bernhard
Hello David,
I could find an issue with konsole freezing
and reported it in this bug:
https://bugs.debian.org/931844
Maybe you want to have a look if you find your issue there.
Kind regards,
Bernhard
Package: libqt5gui5
Version: 5.11.3+dfsg1-1
Severity: wishlist
Tags: upstream
Affects: konsole orca
Dear Maintainer,
I noted some recent additions to bug #594506 which I guess
describe a different problem. I did some investigations and
tripped on the issue with following steps:
- Installed in a
Package: orca
Version: 3.30.1-1
Severity: normal
Dear Maintainer,
I was trying to triage another bug by using orca
inside a minimal Buster amd64 qemu VM.
On that minimal system I installed just:
apt install systemd-coredump xserver-xorg sddm plasma-desktop orca
When I tried to start orca in
Hello Francis Laniel,
I am just looking at some crashes in some random packages,
and found this nouveau issue familiar.
I guess __pthread_cond_wait_common should be able to
handle a NULL for abstime - e.g. should "Block without a timeout".
Hello David,
I am not involved in packaging, just tried to collect some more
information to this old bug.
I guess your issue migth not be that one discussed in this bug.
At least you might be able to provide the output of 'dmesg',
if in your case konsole really crashes.
Or after installing the
Dear Maintainer,
I tried to reproduce this issue and received the below backtrace.
This seems the same issue as in following bugs:
https://bugs.debian.org/924499
https://bugs.debian.org/928264
(And a few other reported just against current testing.)
Kind regards,
Bernhard
(gdb) bt
#0
Dear Maintainer,
I just tried to help triaging this bug.
This bug manifests in current Stretch/9.9 and
also in Buster/testing.
In the call to function setMultiStats a temporary
PLAYERSTATS object gets constructed from the
reference returned by getMultiStats.
Therefore the copy constructor of
Control: tags -1 + moreinfo
Hello Iris,
I tried to collect some more information for the maintainer.
But I could not find a problem installing and running
zenity inside a minimal Stretch qemu VM,
that has no SSE support (-cpu pentium2 -no-kvm).
Therefore some more information might be needed:
Hello Avinash Sonawane,
unfortunately in my test setup I still get not near that location.
Therefore maybe the maintainer or upstream would need to have a look.
But I fear, as the buster release is in sight and libwebkitgtk
got replaced by libwebkit2gtk, the time that gets invested into
this
Dear Maintainer,
looks like the submitter opened in response to the last
mail bug #930649 against src:linux.
Therefore this one might be closed?
Kind regards,
Bernhard
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930649
Dear Maintainer,
unfortunately I got the impression that upstream bugs [1] and [2]
would really have been the same and therefore assumed the patch
[2] would actually fix this bug too.
Actually I guess just [1] is the right one - based on the
linked retrace.fedoraproject.org backtrace.
However, on
Hello Gulfstream,
are you by any chance running the proprietary nvidia drivers?
I guess the output of following commands could be
helpful for the maintainer to diagnose this issue.
Could you run them and forward the output to this bug?
which freecad
ldd /usr/bin/freecad
dpkg -S
Hello Avinash Sonawane,
I just tried to help triaging this crash.
Unfortunately I could not reproduce this crash
in a minimal stretch VM.
If you can still reproduce the crash, maybe you could
install the following debug information packages before,
and repeat the 'midori -g' step:
Dear Maintainer,
I just tried to reproduce the crash and succeeded
in a wayland session.
Following are the last frames where gedit aborts,
with debug symbol.
When debugging the issue it looks like we reach already line 327
with the pointer in "start" being higher that that in "end".
Therefore
"libpixman|libcairo2|libchamplain|libffi6|libgjs0g|libmozjs|libglib2.0|libgtk-3|gnome-maps"
| sort
Kind regards,
Bernhard
Am 01.06.19 um 08:16 schrieb Saša Janiška:
> Bernhard Übelacker writes:
>
>> And send another output of journalctl, that way the function
>> names fo
Hello Saša Janiška,
thanks for your fast response.
Maybe you could also install following debug symbol packages:
libpixman-1-0-dbgsym libcairo2-dbgsym libchamplain-0.12-0-dbgsym
libffi6-dbg libgjs0g-dbgsym libglib2.0-0-dbgsym libgtk-3-0-dbgsym gjs-dbgsym
(and if size does not matter:
Hello Andy Dorman,
the new location seems to be in the following directory:
root@debian:~# dpkg -L libtcmalloc-minimal4 | sort
...
/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal_debug.so.4
/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal_debug.so.4.5.3
Hello James Henried,
I guess this issue could be related to following shared library.
> 0x77b6a0e0 0x77b7af47 Yes (*)
> /usr/local/lib/libimobiledevice.so.6
It looks like this file is a manual installed version,
while the debian version of that library should be loaded
Control: tags -1 + moreinfo
Hello Saša Janiška,
I just tried to reproduce the issue but for me it did not show up.
Therefore a few more information may be required.
Your desktop is running a xorg or wayland session?
Was this just crashing once or can you reproduce it again?
Maybe you could
Control: tags -1 - moreinfo
Hello Shawn Landden,
> Good point. I started ddd from a terminal. Ctrl-c is ignored.
I just saw that Ctrl-c is not terminating ddd, but
in the debugger console following is shown:
(gdb) Quit
(gdb) Quit
So it looks like it just get forwarded to the gdb process.
Dear Maintainer,
I just tried to reproduce this crash and may have
found some more information.
It looks like this memory got freed already at
this location [1].
Then on the second free attempt the talloc
recognises this and aborts [2].
Could not find a related upstream bug report in [3].
It
Control: tags -1 + moreinfo
Hello Shawn Landden,
where exactly do you enter this ctrl-z?
In the graphical user interface of ddd ctrl-z is the shortcut for the
Edit - Undo action. So that is not supposed to end ddd, I guess.
Or do you enter it in a terminal from which you started ddd?
>From
Control: tags -1 + moreinfo
Hallo James Henried,
was just looking through some random bug reports.
Maybe you could install the package systemd-coredump.
That way in the journal would appear a backtrace that
could give some hints where the segmentation fault happens.
Visible in the output of:
Dear Maintainer,
I just tried to have a look at this
backtrace by the submitter:
Thread 1 (Thread 0x7f81021b1e00 (LWP 3464)):
...
#6 0x7f810411f 730 in () at libpthread.so.0
#7 0x56302b0c9 97f in ()
#8 0x56302b0c9 c28 in ()
#9 0x7f8104303 dd8 in
Control: tags -1 - moreinfo
Hello Bardot Jerome,
unfortunately the debug information did not yet cover
all functions in the backtrace.
The backtrace would be perfect if libdrm-nouveau2-dbgsym
would be installed.
But from the visible parts, following issues seem simliar,
at least the "Assertion
Control: tags -1 patch
Dear Maintainer,
I am just looking at some random bug reports with crashes.
In this case I think atril is or was not prepared to run
in a wayland session.
Attached patch is based on some porting guide to wayland and
with that atril shows its main window. Nothing more was
Control: tags -1 moreinfo
Hello Bardot Jerome,
I am just looking at some random bug reports with crashes.
The last page of the strace output might point into the
direction of the graphic driver, you are using the free
nouveau driver?
For more information you might consider adding the dbgsym
Am 28.05.19 um 11:56 schrieb Fabian Greffrath:
> Is it just my MUA again or is this indeed missing the patch?
I am sorry but this time it might be your MUA.
The patch is now visible on the bug's page:
Control: tags -1 patch upstream
Dear Maintainer,
I tried to have a look at this crash and I think I found something.
It seems to be caused by this function in class NoSpecial:
float radius() const {}
It is declared as returning float, but does not return a value.
In the build logs is
Dear Maintainer,
I just tried to have a look and might found something.
As far as I see ldd searches the shared objects based on the RPATH in
the executable:
benutzer@debian:~$ ldd /usr/bin/CloudCompare | grep "not found"
libQCC_IO_LIB.so => not found
Hello Francois,
it looks like your email did not contain any newlines.
Therefore it seems like the whole email was interpreted as the "package".
You can see what I mean in this page [1] near
"Bug reassigned from package".
Kind regards,
Bernhard
[1]
Control: reassign 928892 sponsorship-requests
Hello Francois,
it looks like somthing ate all newlines in your email.
I hope it is ok if I reassign to sponsorship-requests.
Kind regards,
Bernhard
Control: tags 928710 + upstream
Control: forwarded 928710 https://bugs.kde.org/show_bug.cgi?id=381644
Dear Maintainer,
above the upstream bug of this issue.
Kind regards,
Bernhard
Control: tags 928687 + upstream patch
Dear Maintainer,
this could be reproduced from a stored RDP connection entry,
while the plugin is uninstalled.
With the dbgsym package installed the backtrace looks like below.
Unfortunately the null pointer in gp->priv->plugin seems to get
unconditionally
Control: found 855124 2.2.17-1.1+b1
Control: fixed 855124 2.2.17-1.2+b1
Dear Maintainer,
this issue seems to be a problem with the default python
pointer/int sizes which seem to default
to 32 bit in stretch on amd64.
Attached patch tries to declare these to avoid the crashes.
For some reason
Control: tags 907348 + patch upstream
Dear Maintainer,
I tried to have a look and tracked it down into the file
lib/leap-seconds.def which is generated by ltrcc.
Unfortunately this generator seems not prepared for at least i386.
With attached patch the generated file is equal to one
generated
Control: reassign 928498 gtksourceview3 3.24.9-2
Control: tags + 928498 upstream fixed-upstream patch
Control: affects 928498 gitg gedit
Dear Maintainer,
this crash seems to be described in upstream
bugs [1] and [2].
And upstream seems to have a fix commited
to the 3.24 branch [3] too.
A
Hello Joe Ma,
On Sun, 20 Jan 2019 19:59:27 +0800 Joe Ma wrote:
> Hello Bernhard,
> For your question, I do execute your gdb command in the console by a shell
> script when kate freeze. What information do you want me to add? I will
> reply asap.
sorry for the late reply, I did not notice your
Control: tags 886692 + unreproducible moreinfo
Hello Alberto,
I just tried to get some more information from this crash.
I assume this is not caused by the length of the current directory.
Instead I think this is caused by this file:
Control: fixed 893753 leatherman/1.4.2+dfsg-2
Hello,
looks like 1.4.2+dfsg-2 did build without SIGSEGV.
https://buildd.debian.org/status/logs.php?pkg=leatherman=x32
Kind regards,
Bernhard
Hello François,
I just tried to reproduce this crash, without being involved
in packaging qemu.
But could not get my VM to crash - it shows just the video,
either with spicy or the virt-manager integrated viewer.
Therefore could you please add the exact VM config? (virsh dumpxml)
This gstreamer
Hello Tomaz Solc,
are you still able to reproduce the crash?
If yes is it possible to install a coredump collector
like systemd-coredump or corekeeper?
With the first following should show something after a crash:
coredumpctl list
And could be examinded by:
coredumpctl gdb
Kind regards,
Hi Benjamin,
> thanks for your support. I installed the packages valgrind-dbg, libc6-l10n
> and locales
> so that we can compare our systems. But the problem is still present.
> I attached a file with my debugging output.
Looks quite equal, except kernel and cpu.
Maybe the commands below can
Hello André Isidoro Fernandes Esteves,
> I have installed inkscape/experimental,now 1.0~alpha-1 amd64 with no
> problems whatsoever.
> So now i can't test the bug. Sorry :(
Glad to hear it is working.
Just to clarify: I guess that on your system the file
Hello Benjamin Wozniak,
I just wanted to help triaging this issue.
For this I started a qemu vexpress-a15 emulation
with current Buster armhf installed.
Unfortunately I could not reproduce this valgrind error.
Some more details about my test in attached file.
So maybe the valgrind maintainer
Looping in BTS again.
Weitergeleitete Nachricht
Betreff: Re: Bug#922097: inkscape stops with message complaining about
an internal illegal instruction on start
Datum: Wed, 1 May 2019 16:14:36 +0100
Von: André Esteves
An: Bernhard Übelacker
I have installed inkscape
Control: reassign 928264 libgeocode-glib0 3.20.1-2
Control: tags 928264 + upstream fixed-upstream patch
Control: affects 928264 gnome-maps
Control: fixed 928264 libgeocode-glib0/3.26.1-1
Dear Maintainer,
I just tried to reproduce and hit the segfault below [3].
This seems to be reported in bugs
Hello André Isidoro Fernandes Esteves,
do you still see this crash?
If yes, could you please provide the output of following search:
grep -Rn arbow_type /usr
If you create another user, is the problem also visible there?
Kind regards,
Bernhard
Control: reassign 927954 libdrm-nouveau2 2.4.97-1
Control: affects 927954 + konqueror
Hello Osama Nasr,
> I'm so sorry for that,
> I just reinstalled KDE and every thing works fine,
> I'm sorry if that a waste of your time.
Glad to hear that it is working.
But as this might be a threading
Hello Osama Nasr,
> oh, this system is running in a VM, that
> might be important information.
>
> But I'm runing it as my main OS, I mean I'm not runnig on VM.
>
> BTW, when using Budgie, the problem disappear...
What output gives this command:
lspci -nn | grep VGA
Kind regards,
Hello Osama Nasr,
> glxinfo -B
> name of display: :0
> display: :0 screen: 0
> direct rendering: Yes
> Extended renderer info (GLX_MESA_query_renderer):
> Vendor: VMware, Inc. (0x)
> Device: llvmpipe (LLVM 7.0, 256 bits) (0x)
oh, this system is running in a VM, that
Hello Adrian,
so unfortunately it has still no clear error.
In your .xsession-errors is tcosmonitor mentioned.
As this package got 2016 removed [1] from debian - do you
have still installed tcosmonitor or tcosmonitor-common?
If yes, maybe that might cause some troubles?
If no, which file tries
Hello Adrian,
> Using a console login and startx, everything works fine though.
>
> Logging in into amiwm works fine though!
>
> I also can't use a session created through xdm or a login manager
> because a lot of GNOME and GTK complain or even seqfault and won't
> start after creating a
Hello Osama Nasr,
> Thanks a lot for your help, but actually i don't need that app, I just
> was reporting this bug.
I am also not involved in packaging konqueror, just tried to collect
some more information, for the maintainers to work with.
> Do you need me to install proprietary drivers
Hello Osama Nasr,
> By the way, I've installed GIMP, although there was a bug
> (libmypaint-common #906144).
> I don't know if that have a relation or not.
On a short look I guess this is not related.
> konqueror: ../nouveau/pushbuf.c:723: nouveau_pushbuf_data: Assertion
> `kref'
Hello Osama Nasr,
please use the "reply all" to answer - that way the information
is automatically stored also in the bugs web site:
https://bugs.debian.org/927954
Kind regards,
Bernhard
Am 25.04.19 um 18:19 schrieb Osama Nasr:
> By the way, I've installed GIMP, although there was a bug
Control: retitle 927940 [Windows Subsystem for Linux] Applications cannot find
libQt5Core.so.5
Hello Ryo,
> I encountered this problem with my WSL environment.Not quite the usual kernel
> ... ;-)
A google search leads to this information [1]
and this bug [2].
There a workaround is provided
Hello Osama Nasr,
I tried to reproduce this issue in a minimal Unstable VM
with plasma-desktop and konqueror installed.
But could not reproduce it.
Could you try to start it from a konsole and forward
the output you get there after you hit this bug?
And have you configured something non-default
Hello Ryo IGARASHI,
I just trying to triage this bug, and have in a minimal
Buster amd64 VM installed just paraview installed and
could not reproduce the issue.
Could you please check the output in your system for any
differences to the outputs below:
dpkg -l | grep -E
Control: tags 924445 + moreinfo
Hello Joshua,
the given information seems not sufficient to start investigation.
Therefore, if you still can observe this crash, you might install
the packge systemd-coredump, trigger the crash, then retrieve
the output of following command and forward it to this
Dear Maintainer,
I just tried to find some more information.
I could reproduce the issue in a unstable amd64 VM
on the second attempt.
It looks like in a garbage collector run a
division by zero is triggered because we
get there with sector_size==0.
If wanted I can forward the core file.
Kind
Hello gpe,
this stack trace looks really like that one
submitted in https://bugs.debian.org/927728 .
Possibly you can install just libgeocode-glib0 3.26.1-1
from unstable?
>From my findings in https://bugs.debian.org/927728
I would expect that this crash should then be gone.
Kind regards,
Hello gpe92,
maybe you could add some more information for the maintainer
by following steps, if possible:
- install the package "systemd-coredump"
- try to start gnome-maps again
- forward the output of following command to this bug:
journalctl | sed -n '/dumped core/,/systemd-coredump@/p'
I
Hello Daniel Kahn Gillmor,
the backtrace looks similar to that from this bug:
https://bugs.debian.org/924029
Kind regards,
Bernhard
Hello Paul Wise,
might this be related to #925539 ?
Can you still reproduce it when you install
libgeocode-glib0 3.26.1-1 from unstable?
Kind regards,
Bernhard
https://bugs.debian.org/925539
Hello Dave Kitchen,
I am not involved in packaging kate, just trying to collect
some more information.
You wrote you open via nautilus - so you are running a
Gnome/Wayland desktop session?
I tried to reproduce the issue in a Gnome/Wayland session
but could not find a problem. In kate the native
Hello Pere Nubiola Radigales,
I just saw this report without being involved in packaging freecad.
And tried to reproduce the issue but failed.
Is it possible to save it into a file just before it crashes?
Can the crash be reproduced by starting from that file?
Otherwise you could install the
Control: tags 922943 + upstream fixed-upstream patch
Control: tags 319221 + upstream fixed-upstream
Dear Maintainer,
this bug seems to be a duplicate of #319221,
which got forwarded and fixed upstream.
Attached is a targetted patch, slightly changed from
upstream [1] to apply, just resolving
Dear Maintainer,
one short addition, I tried to install to a current buster system
some versions from snapshot.debian.org.
Some versions around Stretch release allow a connection and
interacting with the desktop is possible.
Just on disconnect Xtigervnc crashes but cannot
say if that is related.
Control: found 922323 0.9.20180101-1+b1
Control: tags 922323 + upstream
Dear Maintainer,
I tried to have a look at this segfault, and guess I
have found something.
The problem seems to be, that the slirp library used
by Basilisk is using some 32 bit types for pointers.
Unfortunately this does
Control: reassign 923962 libunwind8 1.2.1-9
Control: affects 923962 tigervnc
Dear Maintainer,
I guess this could be a problem in libunwind8 at aarch64.
Please find in message #15 some more details.
Kind regards,
Bernhard
#15 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923962#15
Dear Maintainer,
I just tried to collect some more info from this crash.
I got this by using "peek --backend=gnome-shell"
inside a gnome/wayland session.
Using some reverse debugging, I guess all happens below function
peek_post_processing_ffmpeg_post_processor_generate_animation_async_co,
that
Hello Adam Borowski,
I am just looking through crashes of random packages and tried to
get some more information from that.
The line information from your backtrace and that in 268630
looks quite equal, so it might still be the same cause.
In this bug and in 268630 xbindkeys-config might crash
Control: tags 268630 + upstream patch
Dear Maintainer,
I just tried to have a look at 926554, but I think
both are kind of the same.
The issue here is, as far as I see, that in function
middle_get_key a process "xbindkeys -k" gets started
and its output is tried to be parsed.
Unfortunately if
Dear Maintainer,
from the segfault and also the code line this
may be a duplicate of #926212.
At least the crash points to the same source line:
src/shell-app.c, line 1485.
Kind regards,
Bernhard
#926212 https://bugs.debian.org/926212
# Buster amd64 qemu VM 2019-04-19
apt update
apt
Hello Marcus Lundblad,
I don't know if it is related - I own a Baytrail
device that contains also these axp devices.
Back in late 2017 I got some help from Hans de Goede,
who worked that time in that area.
There my battery information was also missing with
the stock debian kernel.
He suggested to
Hello Johan Mollevik,
I am maintaining neither python, gdal or matplotlib, was
just trying to reproduce the memory error.
Unfortunately it worked in my minimal test VMs without
crash or fault.
Comparing the versions of my tests led me to the question
if the system, where you experience this
Am 17.04.19 um 09:04 schrieb Bernhard Reiter:
> Am Dienstag 16 April 2019 22:32:30 schrieb Bernhard Übelacker:
>> - Signature Validation: Signature is Valid.
>> - Certificate Validation: Certificate has Expired
>
> Looks good, so it seems that libnss3 has a differ
On Tue, 16 Apr 2019 22:47:14 +0100 Simon McVittie wrote:
> How sure are you that the virtual memory area starting at 0x7fd4fa6a6000
> starts with .init and not .text?
Unfortunately I am not completely sure, but I caused a crash while
knowing the memory layout and found there also the dmesg line
Dear Maintainer,
tried to have another look with the original input file.
In my minimal test VM I came again across the segfault I
described in message #10, which is not the
problem Wesley hit and got sumitted in #926404 too.
So I had to start firefox once to have a profile
in the home directory.
Am 16.04.19 um 12:04 schrieb Bernhard Reiter:
>> there was neither /etc/pki/nssdb nor a firefox profile in the
>> home directory.
>
> Can you post the signature information?
> My guess from the code is that you saw the info,
> but no certification validation.
benutzer@debian:~$ /usr/bin/pdfsig
Hello Kim-Alexander,
thank you for the fast response.
I loaded the core and found following backtrace.
(Information how to retrieve it attached.)
Kind regards,
Bernhard
(gdb) bt
#0 0x7f65d13e3dd9 in __bswap_32 (__bsx=) at
/usr/include/x86_64-linux-gnu/bits/byteswap.h:52
#1
Hello Bernhard,
> The indicateion is the difference in the messages in the original problems:
> #924050: Internal Error (0): Input couldn't be parsed as a CMS signature
> #926404: Internal Error (0): couldn't find default Firefox Folder
Yes, I fear I hit not the submitters problem in #924050 and
Hello Wesley Schwengle,
I am not sure anymore if the error I received is the same you got.
Therefore, if you can still reproduce this issue, can you please
run pdfsig inside a debugger like below and forward the output to
this bug? You would at least need to install the package 'gdb'.
gdb -q
Control: tags 924050 + upstream fixed-upstream patch
Dear Maintainer,
> Program received signal SIGSEGV, Segmentation fault.
> 0x77321c84 in SECMOD_ReferenceModule () from
> /lib/x86_64-linux-gnu/libnss3.so
> #0 0x77321c84 in SECMOD_ReferenceModule () from
>
Hello Kim-Alexander Brodowski,
I just tried to get some more information from the segfault
lines, while not being involved in packaging.
It seems to point to function sieve_bytecode_version
in sieve/bc_eval.c:1809.
Unfortunately upstream seems to have removed/rewritten that
function completely
Hello Juanjo Espí,
I just tried to reproduce this issue to get some
more informations for the Maintainer.
Unfortunately due to my limited docker
knowledge I was not successful.
Therefore you might supply some more information by installing
gdb, attaching it with following command and then start
Control: tags 927027 + patch
Dear Maintainer,
I tried to have a look at this crash and I think it is related to
the large file support, which is defined in dcfldd.h, line 27 and 28.
Unfortunately this file gets not included first in split.c and
therefore off_t gets defined without large file
Hello Alf,
Am 12.04.19 um 22:10 schrieb Alf:
> I am prepared to test your patch as soon as I get a binary of the
> patched lib.
please find attached some commands to build the package
with the patches in question by yourself.
Maybe you want to do this on a different machine as it
installs quite
Dear Maintainer,
I tried to triage that issue and came to this try and catch block:
146 try {
147 PlainPasswd plainPassword(obfuscated);
148 password->replaceBuf(plainPassword.takeBuf());
149 PlainPasswd plainPasswordReadOnly(obfuscatedReadOnly);
Control: reassign 921266 libbellesip0 1.6.3-4
Control: affects 921266 linphone
Control: tags 921266 + upstream patch
Hello Alf,
> Hope this helps you to locate the root cause.
I had a quick look at this line and found that upstream has
changed these lines already in their repository,
these
Hello Alf,
thanks for the fast response.
You can query to which package a shared object belongs by:
dpkg -S /usr/lib/x86_64-linux-gnu/libbellesip.so.0
That should show 'libbellesip0' I guess.
So, if package libbellesip0-dbgsym gets installed, another
retry should have all needed debug
701 - 800 of 1283 matches
Mail list logo