Bug 358661 – crashed when deleting messages

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 358661 - crashed when deleting messages


Summary:	crashed when deleting messages


Status:	RESOLVED DUPLICATE of bug 357735

Product:	Pan
Classification:	Other
Component:	general
Version:	pre-1.0 betas
Hardware:	Other All

Importance:	Normal critical
Target Milestone:	---
Assigned To:	Charles Kerr
QA Contact:	Pan QA Team

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2006-10-01 01:18 UTC by David Kelly
Modified:	2006-10-06 16:08 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
0.115 patch (1.37 KB, patch) 2006-10-06 16:08 UTC, Charles Kerr	none	Details \| Review

Description David Kelly 2006-10-01 01:18:13 UTC

Steps to reproduce:
1. My primary news server has been acting up this weekend. Many parts were missing downloaded wtih 0.114.
2. Added a backup news server and tried "Download all Headers" to try to complete the missing parts and get nice green icons rather than broken reds. Didn't seem to contact the backup at all.
3. Saw 0.115 was out. Downloaded, compiled, installed, and started where 0.114 left off.
4. Have 2 connections to primary, 4 to backup, and saw Pan running 6 connections with "download all headers"
5. Had downloads running in a different group, having filled in the missing pieces.
6. Download new headers in a group other than where the downloads were coming from.
7. Crashed when I deleted some of the new messages that arrived.

I think some of the message headers I deleted were same I had deleted previously when only one news server was configured. That they came back when found on the backup server.

I am particularly skilled in crashing while deleting messages.

Nuked ~/.pan2 with my 0.114 upgrade so there shouldn't be any old artifacts laying around due to crashes. Don't remember if I managed to crash 0.114 or not.

Stack trace:
(gdb) thread apply all bt

+ Trace 73832

Thread 4 (LWP 100136)

#0 pthread_testcancel
from /usr/lib/libpthread.so.2
#1 pthread_mutexattr_init
from /usr/lib/libpthread.so.2
#2 ??

Thread 3 (Thread 0x8296000 (runnable))

#0 pan::DataImpl::xover_add
at quark.h line 156
#1 pan::TaskXOver::on_nntp_line
at string-view.h line 147
#2 pan::NNTP::on_socket_response
at nntp.cc line 143
#3 pan::GIOChannelSocket::do_read
at string-view.h line 149
#4 pan::GIOChannelSocket::gio_func
at socket-impl-gio.cc line 482
#5 g_vasprintf
from /usr/local/lib/libglib-2.0.so.0
#6 g_main_context_dispatch
from /usr/local/lib/libglib-2.0.so.0
#7 g_main_context_acquire
from /usr/local/lib/libglib-2.0.so.0
#8 g_main_loop_run
from /usr/local/lib/libglib-2.0.so.0
#9 gtk_main
from /usr/X11R6/lib/libgtk-x11-2.0.so.0
#10 (anonymous namespace)::run_pan_in_window
at pan.cc line 154
#11 main
at pan.cc line 294

Thread 2 (Thread 0x8ad2400 (LWP 100057))

#0 pthread_testcancel
from /usr/lib/libpthread.so.2
#1 pthread_mutexattr_init
from /usr/lib/libpthread.so.2
#2 ??

Thread 1 (Thread 0x8ad2600 (sleeping))

#0 pthread_mutexattr_init
from /usr/lib/libpthread.so.2
#1 pthread_mutexattr_init
from /usr/lib/libpthread.so.2
#2 _pthread_cond_wait
from /usr/lib/libpthread.so.2
#3 pthread_cond_wait
from /usr/lib/libpthread.so.2
#4 g_async_queue_push_sorted
from /usr/local/lib/libglib-2.0.so.0
#5 g_thread_pool_free
from /usr/local/lib/libglib-2.0.so.0
#6 g_static_private_free
from /usr/local/lib/libglib-2.0.so.0
#7 pthread_create
from /usr/lib/libpthread.so.2
#8 _ctx_start
from /lib/libc.so.6
#0 pthread_testcancel
from /usr/lib/libpthread.so.2



Other information:
Pan 0.115, FreeBSD 6.1

Comment 1 Charles Kerr 2006-10-01 04:23:25 UTC


*** This bug has been marked as a duplicate of 357735 ***

Comment 2 Charles Kerr 2006-10-06 16:08:14 UTC

Created attachment 74153 [details] [review]
0.115 patch

Aaaaaaaah, I see the problem now.

Also while we're in the neighborhood, a minor tweak to Quark
to avoid creating temporary a StringView object when testing
a Quark and StringView for equality.