Pan crashes on every reply sent.

[Frederic Bezies]

Hello.

Very annoying bug using last git commit available.

When I try to post a reply, pan crashes.

Here is the message I get when I launch it from terminal :

[***@fredo-arch src]$ terminate called after throwing an instance of
'std::length_error'
what(): basic_string::resize

[1]+ Abandon pan

Any idea ?

[Duncan]

Post by Frederic Bezies
Hello.
Very annoying bug using last git commit available.
When I try to post a reply, pan crashes.
'std::length_error'
what(): basic_string::resize
[1]+ Abandon pan
Any idea ?

Well, if you'd have used pan to post this (using gmane.org's list2news
service, as I do, or whatever), the pan user-agent header might have
given us the relevant info on git branch and commit number, etc, but you
didn't, and you didn't post that info, so I get to ask... but at least
you DID post that it's git, not the release version.

Since you didn't say, you're presumably using the the official gnome repo,
not khaley/lostcoder's github repo, or someone else's there. But master
branch, or the new testing branch that hmueller's running that was
previously on github as the judgefudge repo (and before that as the
imhotep82 repo).

Many regulars here (including me) run the hmueller experimental/testing
branch, since that's where the current action and new goodies seem to be,
but it /is/ pretty raw and /does/ break sometimes. And since you didn't
say, the default would presumably be master branch, except that so many
here run experimental... So there's no real assumable default at this
point.

And of course, the git commit would be useful as well.

FWIW as I said, I run hmueller's branch, now official gnome upstream
testing branch, but I've not updated in a few days. The git-commit is as
I said in the user-agent header. It sort of includes branch as well, but
at least as it shows up in my headers, that's the local bare-branch that
portage pulls using my customized pan ebuild, so while the occurrance of
portage in the string is a strong indication that I use gentoo, and the
path leaks some information about my local directory layout, it doesn't
say anything about the upstream branch I'm pulling from as that feature
is actually intended to do.

But with the caveat that I run that testing branch and haven't pulled in
a few days so am almost certainly behind, I've not seen any such
behavior, here. That might help narrow down the commit range in which
the problem occurs if you use gnome/testing as well, or it might not, as
it could just as easily be a difference in library version, or if you're
on 32-bit, maybe it only happens there, since I'm running amd64/x86_64.

[Frederic Bezies]

Post by Duncan

Post by Frederic Bezies
Hello.
Very annoying bug using last git commit available.
When I try to post a reply, pan crashes.
'std::length_error'
what(): basic_string::resize
[1]+ Abandon pan
Any idea ?

Well, if you'd have used pan to post this (using gmane.org's list2news
service, as I do, or whatever), the pan user-agent header might have
given us the relevant info on git branch and commit number, etc, but you
didn't, and you didn't post that info, so I get to ask... but at least
you DID post that it's git, not the release version.

Sorry for not posting infos.

I'm using latest code from master, revision : (GIT 37631e6 master;
x86_64-unknown-linux-gnu)

My linux distro : archlinux, 64 bits, gnome-shell 3.2.x

My gcc :

[***@fredo-arch objdir-blue]$ gcc --version
gcc (GCC) 4.6.2 20111125 (prerelease)

[...]

Post by Duncan
And of course, the git commit would be useful as well.

I'm using pan updated to this commit :

http://git.gnome.org/browse/pan2/commit/?id=37631e661d54643cabe4f3376b9cc18778a16f78

Reverting it helped me getting back my delete key to work.

Post by Duncan
FWIW as I said, I run hmueller's branch, now official gnome upstream
testing branch, but I've not updated in a few days. The git-commit is as
I said in the user-agent header. It sort of includes branch as well, but
at least as it shows up in my headers, that's the local bare-branch that
portage pulls using my customized pan ebuild, so while the occurrance of
portage in the string is a strong indication that I use gentoo, and the
path leaks some information about my local directory layout, it doesn't
say anything about the upstream branch I'm pulling from as that feature
is actually intended to do.

I think I found guilty commit. Here is what I wrote directly to hmueller :

"It is this one, well, after reverting it, no more crashes.

http://git.gnome.org/browse/pan2/commit/?id=bc7803590ebfdcbbbbdfa2f7dbe24253838193c8

If it is applied, every single time I want to sent a reply or a message,
pan crashes with this error :

[***@fredo-arch src]$ terminate called after throwing an instance of
'std::length_error'
what(): basic_string::resize"

So a 6 days old "regression" :(

Post by Duncan
But with the caveat that I run that testing branch and haven't pulled in
a few days so am almost certainly behind, I've not seen any such
behavior, here. That might help narrow down the commit range in which
the problem occurs if you use gnome/testing as well, or it might not, as
it could just as easily be a difference in library version, or if you're
on 32-bit, maybe it only happens there, since I'm running amd64/x86_64.

No, 64 bits here.

Reverting commit bc7803590ebfdcbbbbdfa2f7dbe24253838193c8 fix the problem.

[Duncan]

Post by Frederic Bezies

Post by Duncan

Post by Frederic Bezies
Hello.
Very annoying bug using last git commit available.
When I try to post a reply, pan crashes.
'std::length_error'
what(): basic_string::resize
[1]+ Abandon pan

I'm using latest code from master, revision : (GIT 37631e6 master;
x86_64-unknown-linux-gnu)
My linux distro : archlinux, 64 bits, gnome-shell 3.2.x

archlinux, cool! =:^) A lot of gentoo users go there if they want
something a bit easier, but still not ye-olde-standard-bindist. gentoo
fits me about perfectly so I'm not personally likely to change in the
short or medium term myself, but who knows what'll happen longer term.
Meanwhile, the arch wiki seems to be where people go for tough issues
these days... it used to be gentoo's docs, which unfortunately aren't as
current as they were years ago (tho one of the docs devs from back in the
day is back with gentoo now, and there've been quite some improvements in
just the quarter or so he's been back! =:^)

But for a (core) desktop I'm more a kde user, no gnome installed, but
more gtk apps especially recently, due to the kdepim akonadification/
breakification. But I've been on pan for close to a decade, now. =:^)

Post by Frederic Bezies
(prerelease)
[...]

Post by Duncan
And of course, the git commit would be useful as well.

http://git.gnome.org/browse/pan2/commit/?

id=37631e661d54643cabe4f3376b9cc18778a16f78

Doing git show on that commit here... results in a bad object error... so
I guess that's after my last update. I'll update again in a couple days,
tho, maybe even today, and see at that point, altho as I said I'm
normally testing branch. Tho I could of course switch to master branch
to test this, if it's still an issue by the time I get a properly
circular tuit. =:^)

(I had been close to three months behind on LWN's weeklies, so that's
been my project this week, catching up there. I'm only a weeky and a
half behind now, so I'm getting close. Between that and the kde 4.7.90
aka 4.8-beta2 update I did yesterday, I've been too busy to worry about
updating my live-builds, including pan, when they're working reasonably
well at the point they're at.)

Post by Frederic Bezies
Reverting it helped me getting back my delete key to work.

Post by Duncan
FWIW as I said, I run hmueller's branch, now official gnome upstream
testing branch, but I've not updated in a few days.

"It is this one, well, after reverting it, no more crashes.
http://git.gnome.org/browse/pan2/commit/?

id=bc7803590ebfdcbbbbdfa2f7dbe24253838193c8

I don't see that one here either. So yeah, I'm behind.

Post by Frederic Bezies
If it is applied, every single time I want to sent a reply or a message,
'std::length_error'
what(): basic_string::resize"
So a 6 days old "regression" :(
No, 64 bits here.
Reverting commit bc7803590ebfdcbbbbdfa2f7dbe24253838193c8 fix the problem.

FWIW, if you're running either of the gnome branches, if you're not
following the pan-dev list you might want to subscribe to it, too. The
pan community hasn't been too strict about which posts go to which list
and discussion of git-branch developments happen on both lists, so
posting to either is fine, but there are people that prefer to post there
for git-build issues, so if you want to keep up you really do need to
follow both. Not that there's enough traffic on either to make it a
major problem keeping up, but they are both used.

[fredbezies]

[...]

Post by Frederic Bezies

Post by Frederic Bezies
http://git.gnome.org/browse/pan2/commit/?

id=37631e661d54643cabe4f3376b9cc18778a16f78
Doing git show on that commit here... results in a bad object error... so
I guess that's after my last update.  I'll update again in a couple days,
tho, maybe even today, and see at that point, altho as I said I'm
normally testing branch.  Tho I could of course switch to master branch
to test this, if it's still an issue by the time I get a properly
circular tuit. =:^)

I saw that hmueller make commits on both branches, so...

Post by Frederic Bezies
(I had been close to three months behind on LWN's weeklies, so that's
been my project this week, catching up there.  I'm only a weeky and a
half behind now, so I'm getting close.  Between that and the kde 4.7.90
aka 4.8-beta2 update I did yesterday, I've been too busy to worry about
updating my live-builds, including pan, when they're working reasonably
well at the point they're at.)

This "regression" is 6 days old, so you escaped it ;)

[...]

Post by Frederic Bezies

Post by Frederic Bezies
Reverting commit bc7803590ebfdcbbbbdfa2f7dbe24253838193c8 fix the problem.

FWIW, if you're running either of the gnome branches, if you're not
following the pan-dev list you might want to subscribe to it, too.  The

I will do this.

Post by Frederic Bezies
pan community hasn't been too strict about which posts go to which list
and discussion of git-branch developments happen on both lists, so
posting to either is fine, but there are people that prefer to post there
for git-build issues, so if you want to keep up you really do need to
follow both.  Not that there's enough traffic on either to make it a
major problem keeping up, but they are both used.

I will suscribe and report the problem. Thanks for the tip ;)

Post by Frederic Bezies
--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[Duncan]

Post by fredbezies
I will suscribe and report the problem. Thanks for the tip ;)

Well, what I was trying to say is that since the problem was posted here
already, that should be enough (no need to repost there), and indeed,
post to whichever list you want when it's a git issue... just that you
might want to subscribe there too, in ordered to keep up with
developments that might be posted to only one list or the other, not both.

An example would be hmueller's announcement that this pan tree, formerly
on github as judgefudge/pan2, was now moved to the official gnome pan
repo, as the testing branch. Originally he posted that announcement to
the dev list only... and a few days later we had someone asking here what
happened as he couldn't reach the judgefudge repo on github any longer.
Several answers pointed him at the new gnome repo, testing branch, but
had he been following both lists, he'd have known that already, as he'd
have seen the announcement on the dev list.

So my point was, follow both if you're doing live-git builds, so as to
avoid missing stuff like that. But you can post to either group (well,
list, but it's newsgroup to those like me reading it on gmane).

But I guess I didn't get that clearly conveyed and you posted there too,
which is fine as well, just a bit of unnecessary duplication.


Oh, BTW, you mentioned that you're running gnome3, so of course have gtk3
and perhaps built pan against that instead of gtk2. It's worth noting
that while the pan gtk3 support code is there and it's possible to build
pan against gtk3, that's rather less stable and tested than the gtk2
code. So unless you want to specifically test the gtk3 code, it's
recommended that you build against gtk2 instead, at this point. It'll be
more stable. It's possible that's what was triggering your crashes.

FWIW, I don't have gtk3 on my system at all, only gtk2. I expect things
to get interesting when firefox builds against gtk3 as well as it does
against gtk2, as at that point the pressure will be on to get everything
else switched over to gtk3 as well, but until firefox switches, that's
not going to happen so there's little pressure for anything else. And
last I checked probably a couple months ago, firefox had some major work
to do before it was fully gtk3 compatible. Perhaps sometime next year,
which means that by 2H2012 the pressure could be building for other apps
as well, and leading edge distros will likely be starting to drop gtk2-
only apps in 2013, but I don't seriously expect it much before that.

[Heinrich Mueller]

Post by Frederic Bezies
Sorry for not posting infos.
I'm using latest code from master, revision : (GIT 37631e6 master;
x86_64-unknown-linux-gnu)
My linux distro : archlinux, 64 bits, gnome-shell 3.2.x
gcc (GCC) 4.6.2 20111125 (prerelease)
http://git.gnome.org/browse/pan2/commit/?id=37631e661d54643cabe4f3376b9cc18778a16f78
Reverting it helped me getting back my delete key to work.
"It is this one, well, after reverting it, no more crashes.
http://git.gnome.org/browse/pan2/commit/?id=bc7803590ebfdcbbbbdfa2f7dbe24253838193c8

This commit doesn't contain any std::string calls.
I found the guilty line in my code. Please pull and try again.

Cheers.