GNOME Bugzilla – Bug 270844
too large tasks crash evolution
Last modified: 2006-01-20 22:51:04 UTC
Distribution: Gentoo Base System version 1.6.8 Package: Evolution Priority: Blocker Version: GNOME2.8.1 2.0.2 Gnome-Distributor: Gentoo Linux Synopsis: to large tasks crash evolution Bugzilla-Product: Evolution Bugzilla-Component: Tasks Bugzilla-Version: 2.0.2 BugBuddy-GnomeVersion: 2.0 (2.8.0) Description: Description of the crash: If I try to access large task, evolution crashes Steps to reproduce the crash: 1. Create large Task 2. Try to save it 3. --- BANG --- Expected Results: Not to die How often does this happen? always Additional Information: had saved a small shellscript (~20-30 lines) in a task Debugging Information: Backtrace was generated from '/usr/bin/evolution' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 10338)] [New Thread 32769 (LWP 10343)] [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 10338)] [New Thread 32769 (LWP 10343)] [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 10338)] [New Thread 32769 (LWP 10343)] [New Thread 16386 (LWP 10344)] 0xb742e34b in waitpid () from /lib/libpthread.so.0
+ Trace 53920
Thread 1 (Thread 16384 (LWP 10338))
Unknown reporter: a.faust@gmx.net, changed to bugbuddy-import@ximian.com. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Seems to work for me in 2.0.3
This was the content of the Task: BEGIN:VTODO UID:20041117T144224Z-6671-100-8059-8@workon.fbit DTSTAMP:20040831T120353Z SUMMARY:purge CLASS:PUBLIC PERCENT-COMPLETE:0 PRIORITY:0 SEQUENCE:2 LAST-MODIFIED:20041209T113024 CREATED:20041117T144224 DESCRIPTION:7.5 How can I purge an object from my cache?\n\nSquid does not allow you to purge objects unless it is configured with access controls in squid.conf. First you must add something like\n\n acl PURGE method PURGE\n acl localhost src 127.0.0.1\n http_access allow PURGE localhost\n http_access deny PURGE\n\nThe above only allows purge requests which come from the local host and denies all other purge requests.\n\nTo purge an object\, you can use the squidclient program:\n\n squidclient -m PURGE http: //www.miscreant.com/\n\nIf the purge was successful\, you will see a ``200 OK'' response:\n\n HTTP/1.0 200 OK\n Date: Thu\, 17 Jul 1997 16:03:32 GMT\n Server: Squid/1.1.14\n\nIf the object was not found in the cache\, you will see a ``404 Not Found'' response:\n\n HTTP/1.0 404 Not Found\n Date: Thu\, 17 Jul 1997 16:03:22 GMT\n Server: Squid/1.1.14\n\n#!/bin/bash\n\nif [ -z \"$1\" ]\nthen\n echo Usage `basename $0 ` hostname\n exit\nfi\n\nif [ \"`echo \"$1\" | grep : `\" != \"\" ]\nthen\n host=\"`echo \"$1 | cut -f3 -d\"/\"`\"\nelse\n host=$1\nfi\n\nprintf \"PURGE http://%s/ HTTP/1.0\\n\\n\" \"$host\" >/dev/tcp/localhost/3128\n\nif [ \"`grep \"PURGE http://$host\" /var/secenv/squid/log/access.log | grep TCP_MISS`\" != \"\" ]\nthen\n echo Purged \"$host\"\nelse\n echo Purge $host failed\nfi\n\n END:VTODO
Reproduceable in 2.2.x
Seems like a gtkhtml bug.
Moving it to GtkHtml
*** Bug 273784 has been marked as a duplicate of this bug. ***
*** Bug 306215 has been marked as a duplicate of this bug. ***
I do not get a crash on large tasks. However, I do get a crash for the particular task attached above.
The crash in function g_printf_string_upper_bound used to happen while handling positional parameters in pre-2-2 glib. The current versions do not have this problem. I do not find anything askew in gtkhtml function calling the g_printf_string_upper_bound. It could be due to some invalid values being passed to it from write_html (which is called by e_cal_component_preview_display). I compiled evolution/calendar/gui without the optimizations. Then, the same task file attached above (summary: purge) is displayed without any problems. Evolution calender maintainers: any clues why it is working with evolution's optimization turned off ? Is write_html passing some incorrect values? The reason for my doubt is the code that handles these values in gtkhtml is pretty much stock as it makes direct glib calls and does not play around with the data.
I don't think this is a blocker. Large tasks are not regular scenarios. Changing it to 'Major' with "high" priority.
Moving it to tasks component.
*** Bug 313240 has been marked as a duplicate of this bug. ***
Moving to gtkhtml, I guess this needs to be moved to glib.
Fixed.
*** Bug 318841 has been marked as a duplicate of this bug. ***