GNOME Bugzilla – Bug 170628
gweather not robust against unexpected input
Last modified: 2010-01-24 01:06:13 UTC
Steps to reproduce: My workplace was the target of a DDoS attack which slowed our link to a crowl, the link officially was still up but virtually it was impossible to send or recieve data through it. After a while of this (possibly the first time gweather tried to connect) gweather crashed. Stack trace: I don't have a stack trace right now Other information: System is a debian testting on a dual-cpu intel pentium 4. I was logged in for weeks when it happened.
Thank you for your bug report. I don't know if this is a GNOME problem within gweather itself, or in the fact that the DDoS attack slowed your bandwidth down so much and basically crippled your DNS servers so that the "connection" was still up, but no data could be sent out/in. Now, what do you mean gweather crashed? Did it come up with an "ended unexpectedly" notice or did it just not receive weather data? This is my first bug on GNOME BugZilla (Hey.) and I'm trying to make sure I can understand the bug before I can triage it. Much thanks.
I got the typical "Ended unexpecatdly" window with "report with bug-buddy" (para-phrasing). At the time I couldn't report (because the network was down) so I didn't do it "properly" via bug-buddy. To be clear - the application crashed and disappeared from the gnome panel, and this happened after weeks of smooth operation. The application is on the (default?) "update every 30 minutes" so I have a strong feeling that this happened when on its first attempt to update during the DDoS attack (which took an hour). Thanks for handling this bug, please let me know if I can help further.
No, thank you. The only thing I can gander at potentially being the problem is the DNS.
I think this might be the transient crash that seems to exist in gweather. The one that I can't reliably reproduce.
*** Bug 301867 has been marked as a duplicate of this bug. ***
Retitling the bug report. Some or all of the gweather screen scrapers are not robust against unexpected input. The transparent proxy here seemed to reliably crash gweather by returning a login page when gweather was expecting weather data. This should be pretty easy to test for by changing the URLs gweather uses to something else and seeing what happens.
Marking this as a possible gnome-love bug.
*** Bug 303861 has been marked as a duplicate of this bug. ***
*** Bug 301805 has been marked as a duplicate of this bug. ***
Mentioned in https://launchpad.net/products/gnome-applets/+bug/54132 with 2.14.2 as well, bumping Version.
debug backtrace from the Ubuntu bug: "Backtrace was generated from '/usr/libexec/gweather' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1223660640 (LWP 5579)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 69767
Created attachment 69884 [details] [review] check for null pointers This patch fixes various possible pointer issues throughout the routine bom_parse.
Created attachment 69885 [details] [review] check for null pointers oops, posted the wrong one
Created attachment 69886 [details] [review] check for null pointers er, will the real patch please stand up. I've got it under control now. This is the last one I'm posting. I appologize for the mess. :)
Looks pretty good. We should put HEAD and gnome-2-14. BOM code is Australia specific. There are likely to be other errors around too. Some of these have been hidden in duplicates, eg. #317206.
Yes, I tested it using Australian locations. I agree there could be others like this too. I had a quick look but admittedly haven't spent much time with it yet, but I will.
Created attachment 69897 [details] [review] validate pointers in parsing routine Davyd, here's another fix. This time in weather-met.c in the routine met_parse. I've applied the same treatment as the patch I provided for bom_parse. I don't know for sure if this was the cause to the other bugs duped to this one, but the bt for #317206 does point to metoffice_start_open which is in the same module as met_parse.
Comment on attachment 69897 [details] [review] validate pointers in parsing routine >-static gchar *met_parse (gchar *meto, WeatherLocation *loc) >+static gchar *met_parse (gchar *meto) Why break this API?
Actually, ignore me. I just realised this was a static. Need more coffee it seems.
Comment on attachment 69886 [details] [review] check for null pointers Committed to gnome-2-14 and in 2.14.3.
*** Bug 172198 has been marked as a duplicate of this bug. ***
2006-08-07 Davyd Madeley <davyd@madeley.id.au> * weather-bom.c: * weather-met.c: - catch possible NULL pointers when parsing strings. Patches from Kevin Bauder <kevin.bauder@gmail.com>. Closes #170628.