Bug 435960 – crash in Passwords and Encryption Keys: generate new pgp key.

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 435960 - crash in Passwords and Encryption Keys: generate new pgp key.


Summary:	crash in Passwords and Encryption Keys: generate new pgp key.


Status:	RESOLVED INCOMPLETE

Product:	seahorse
Classification:	Applications
Component:	general
Version:	1.0.1
Hardware:	Other All

Importance:	High critical
Target Milestone:	2.20.0
Assigned To:	Seahorse Maintainer
QA Contact:	Seahorse Maintainer

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2007-05-04 21:06 UTC by dondc
Modified:	2007-12-27 22:02 UTC

See Also:
GNOME target:	---
GNOME version:	2.17/2.18

Description dondc 2007-05-04 21:06:59 UTC

What were you doing when the application crashed?
generate new pgp key.


Distribution: Unknown
Gnome Release: 2.18.1 2007-04-16 (FreeBSD GNOME Project)
BugBuddy Version: 2.18.1

System: FreeBSD 6.2-RELEASE-p4 FreeBSD 6.2-RELEASE-p4 #21: Mon Apr 30 17:38:40 CEST 2007     root@dual.virTual.lan:/usr/obj/usr/src/sys/DUALKERN i386
X Vendor: The X.Org Foundation
X Vendor Release: 60899903
Selinux: No
Accessibility: Disabled
GTK+ Theme: Milk 2.0
Icon Theme: gnome

Memory status: size: 49664 vsize: 49664 resident: 23456 share: 70354495 rss: 23456 rss_rlim: 5864
CPU usage: start_time: 0 rtime: 798 utime: 0 stime: 0 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 133

Backtrace was generated from '/usr/local/bin/seahorse'

[New LWP 100117]
[Switching to LWP 100117]
0x2921c671 in wait4 () at wait4.S:2
2	RSYSCALL(wait4)
Current language:  auto; currently asm

+ Trace 132434

Thread 1 (LWP 100117)

#0 wait4
at wait4.S line 2
#1 __waitpid
at /usr/src/lib/libc/gen/waitpid.c line 50
#2 _waitpid
at /usr/src/lib/libpthread/thread/thr_waitpid.c line 48
#3 libgnomeui_segv_handle
at gnome-ui-init.c line 872
#4 _thr_sig_handler
at /usr/src/lib/libpthread/thread/thr_sig.c line 386
#5 ??
#6 ??
#7 ??
#8 ??
#9 ??
#10 _thr_sig_dispatch
at /usr/src/lib/libpthread/thread/thr_sig.c line 285
#11 signal_emit_unlocked_R
at gsignal.c line 2510
#12 IA__g_signal_emit_valist
at gsignal.c line 2199
#13 IA__g_signal_emit
at gsignal.c line 2243
#14 key_changed
at seahorse-keyset.c line 141
#15 seahorse_marshal_VOID__OBJECT_UINT
at seahorse-marshal.c line 119
#16 IA__g_closure_invoke
at gclosure.c line 490
#17 signal_emit_unlocked_R
at gsignal.c line 2440
#18 IA__g_signal_emit_valist
#19 IA__g_signal_emit
at gsignal.c line 2243
#20 key_changed
at seahorse-context.c line 418
#21 IA__g_cclosure_marshal_VOID__INT
at gmarshal.c line 216
#22 IA__g_closure_invoke
at gclosure.c line 490
#23 signal_emit_unlocked_R
at gsignal.c line 2440
#24 IA__g_signal_emit_valist
#25 IA__g_signal_emit
at gsignal.c line 2243
#26 seahorse_key_changed
at seahorse-key.c line 241
#27 changed_key
at seahorse-pgp-key.c line 207
#28 seahorse_pgp_key_set_property
at seahorse-pgp-key.c line 391
#29 IA__g_object_set_valist
at gobject.c line 697
#30 IA__g_object_set
at gobject.c line 1207
#31 add_key_to_context
at seahorse-pgp-source.c line 472
#32 keyload_handler
at seahorse-pgp-source.c line 707
#33 seahorse_load_operation_start
at seahorse-pgp-source.c line 781
#34 seahorse_pgp_source_load
at seahorse-pgp-source.c line 895
#35 seahorse_key_source_load
at seahorse-key-source.c line 94
#36 seahorse_key_source_load_async
at seahorse-key-source.c line 123
#37 scheduled_refresh
at seahorse-pgp-source.c line 542
#38 g_timeout_dispatch
at gmain.c line 3422
#39 g_main_dispatch
at gmain.c line 2045
#40 IA__g_main_context_dispatch
at gmain.c line 2596
#41 g_main_context_iterate
at gmain.c line 2677
#42 IA__g_main_loop_run
at gmain.c line 2881
#43 IA__gtk_main
at gtkmain.c line 1154
#44 main
at main.c line 88

Comment 1 Adam Schreiber 2007-11-09 15:50:09 UTC

Can you reliably replicate this bug?  It looks like some memory is possibly being allocated weirdly on your system in the first call #44.  Looking at the source I don't think that should be happening.

Comment 2 Bruno Boaventura 2007-12-27 22:02:57 UTC

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!