Hi!
* Timo Sirainen t...@iki.fi [2010-03-05 21:07:30 CET]:
On Fri, 2010-03-05 at 20:58 +0100, Jens Peter Secher wrote:
Timo Sirainen wrote:
And the problem is specifically that Dovecot also has
buffer_free() function.
Can you elaborate on this?
I mean both Dovecot and
On 8.3.2010, at 12.03, Gerfried Fuchs wrote:
Either rename buffer_free() on libpam-ssh's side, or mark it in some way
internal to the shared library (I don't know how to do the latter, but I
think it's possible).
As this bug has been reassigned without a version number the BTS
considers
tag 572266 + squeeze sid
thanks
* Timo Sirainen t...@iki.fi [2010-03-08 11:50:33 CET]:
On 8.3.2010, at 12.03, Gerfried Fuchs wrote:
Either rename buffer_free() on libpam-ssh's side, or mark it in some way
internal to the shared library (I don't know how to do the latter, but I
think it's
Hi Rhonsa, Timo,
For me the bug just surfaced sometime in February 2010 on unstable.
So I'd assume it only surfaced for me with the 1.92-10 release.
But I never _configured_ libpam-ssh, and given that the changelog reads:
* Use pam-auth-update together with the new setup file
On Mon, 2010-03-08 at 14:38 +0100, Erich Schubert wrote:
I wonder whether there is a way to check for such errors automatically
with lintian; they are bound to arise now and then, aren't they?
Symbol conflict errors happen somewhat often, and it's sometimes
difficult to detect them. I've had
On 8 March 2010 14:38, Erich Schubert er...@debian.org wrote:
* Use pam-auth-update together with the new setup file
/usr/share/pam-configs/silent-ssh-single-sign-on to automatically
enable the traditional functionality.
My best guess is just that this new configuration setup caused the
Hi all,
So we could do a lintian check that does something like
---
for file in /lib/security/pam_*.so; do
nm -D $file --defined-only | grep -v pam_
done
---
and fails on any results?
For the record:
---
/lib/security/pam_cap.so
00201660 A __bss_start
00201660 A _edata
reassign 572266 libpam-ssh
severity 572266 grave
affects 572266 dovecot-common
thanks
Reason for grave: breaks unrelated software.
(Not sure if the 'affects' syntax is right above, feel free to re-do
that. It makes sense to keep the bug listed as affects to avoid
resubmissions and help other
On 5.3.2010, at 19.46, Erich Schubert wrote:
Thank you - I should've come up with the gdb approach myself.
As expected it is the fault of a PAM plugin, namely libpam-ssh:
Program received signal SIGSEGV, Segmentation fault.
0x08074f4e in buffer_free ()
And the problem is specifically that
Timo Sirainen wrote:
And the problem is specifically that Dovecot also has buffer_free() function.
Can you elaborate on this?
Cheers,
--
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To
On Fri, 2010-03-05 at 20:58 +0100, Jens Peter Secher wrote:
Timo Sirainen wrote:
And the problem is specifically that Dovecot also has buffer_free()
function.
Can you elaborate on this?
I mean both Dovecot and libpam-ssh have an exported function called
buffer_free(). libpam-ssh tries
On Tue, 2010-03-02 at 19:49 +0100, Erich Schubert wrote:
Mar 2 09:35:48 hepcat dovecot: auth(default):
worker-server(erich,127.0.0.1): Aborted: Worker process died unexpectedly
Mar 2 09:35:48 hepcat dovecot: dovecot: child 4865 (auth-worker) killed with
signal 11 (core not dumped)
If
Erich Schubert ha scritto:
Package: dovecot-common
Version: 1:1.2.10-1
Severity: important
On unstable with some bits (unrelated to dovecot) from Debian, dovecot-auth
crashes during password authentication (using local evolution as client):
Mar 2 09:35:48 hepcat dovecot: auth(default):
On Wed,03.Mar.10, 13:26:19, Marco Nenciarini wrote:
To obtain a core dump you should enable them in /etc/defaults/dovecot
and then restart the daemon with /etc/init.d/dovecot restart
$ grep CORE /etc/default/dovecot
ALLOW_COREDUMPS=1
You'll find the resulting core file as
Hi Marco,
I'll do so tonight, when I'm at my home laptop again.
To obtain a core dump you should enable them in /etc/defaults/dovecot
and then restart the daemon with /etc/init.d/dovecot restart
I did that ...
In syslog I still have (core not dumped).
... and had exactly this effect, too.
Andrei Popescu ha scritto:
On Wed,03.Mar.10, 13:26:19, Marco Nenciarini wrote:
To obtain a core dump you should enable them in /etc/defaults/dovecot
and then restart the daemon with /etc/init.d/dovecot restart
$ grep CORE /etc/default/dovecot
ALLOW_COREDUMPS=1
You'll find the
On Wed,03.Mar.10, 23:12:39, Marco Nenciarini wrote:
Could you try to obtain a core after you have amended your configuration
with the attached patch?
Still the same (no core dumps), but I got this:
# /etc/init.d/dovecot restart
Restarting IMAP/POP3 mail server: dovecotWarning: Corrected
Package: dovecot-common
Version: 1:1.2.10-1
Severity: important
On unstable with some bits (unrelated to dovecot) from Debian, dovecot-auth
crashes during password authentication (using local evolution as client):
Mar 2 09:35:48 hepcat dovecot: auth(default): worker-server(erich,127.0.0.1):
18 matches
Mail list logo
