Crash when band width is exhausted

This is the backtrace given in the xsession-errors:

 *** glibc detected *** cairo-dock: double free or corruption (out): 0x000000000$
 ======= Backtrace: =========
 /lib/libc.so.6(+0x725d6)[0x7fa07ca455d6]
 /lib/libc.so.6(cfree+0x6c)[0x7fa07ca4a30c]
 /usr/lib/cairo-dock/libcd-weather.so(cd_weather_reset_weather_data+0x26)[0x7fa0$
 /usr/lib/cairo-dock/libcd-weather.so(cd_weather_update_from_data+0x56)[0x7fa06e$
 /usr/lib/libgldi.so.2(+0x8b57e)[0x7fa07cde157e]
 /lib/libglib-2.0.so.0(+0x46ddb)[0x7fa07e043ddb]
 /lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f3)[0x7fa07e0424a3]
 /lib/libglib-2.0.so.0(+0x45c80)[0x7fa07e042c80]
 /lib/libglib-2.0.so.0(g_main_loop_run+0x182)[0x7fa07e0432f2]
 /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7fa08095c2b7]
 cairo-dock(main+0x11b5)[0x422595]
 /lib/libc.so.6(__libc_start_main+0xfd)[0x7fa07c9f1ead]
 cairo-dock[0x40d4f9]

But is it possible to reproduce this bug and post here the backtrace given by gdb or ddd => http://wiki.glx-dock.org/?p=ddd
(If you already compile the dock by yourself, simply add this CMake flag: -DCMAKE_BUILD_TYPE=Debug)

thanks a lot for the debug !
indeed a gdb backtrace would be more explicit, I'll try to see if I can find
something in the code.

2011/5/26 Matthieu Baerts <email address hidden>

> This is the backtrace given in the xsession-errors:
>
> *** glibc detected *** cairo-dock: double free or corruption (out):
> 0x000000000$
> ======= Backtrace: =========
> /lib/libc.so.6(+0x725d6)[0x7fa07ca455d6]
> /lib/libc.so.6(cfree+0x6c)[0x7fa07ca4a30c]
>
> /usr/lib/cairo-dock/libcd-weather.so(cd_weather_reset_weather_data+0x26)[0x7fa0$
>
> /usr/lib/cairo-dock/libcd-weather.so(cd_weather_update_from_data+0x56)[0x7fa06e$
> /usr/lib/libgldi.so.2(+0x8b57e)[0x7fa07cde157e]
> /lib/libglib-2.0.so.0(+0x46ddb)[0x7fa07e043ddb]
> /lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f3)[0x7fa07e0424a3]
> /lib/libglib-2.0.so.0(+0x45c80)[0x7fa07e042c80]
> /lib/libglib-2.0.so.0(g_main_loop_run+0x182)[0x7fa07e0432f2]
> /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7fa08095c2b7]
> cairo-dock(main+0x11b5)[0x422595]
> /lib/libc.so.6(__libc_start_main+0xfd)[0x7fa07c9f1ead]
> cairo-dock[0x40d4f9]
>
> But is it possible to reproduce this bug and post here the backtrace given
> by gdb or ddd => http://wiki.glx-dock.org/?p=ddd
> (If you already compile the dock by yourself, simply add this CMake flag:
> -DCMAKE_BUILD_TYPE=Debug)
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Team, which is subscribed to Cairo-Dock Plug-ins.
> https://bugs.launchpad.net/bugs/788437
>
> Title:
> Crash when band width is exhausted
>
> Status in Cairo-Dock : Plug-ins:
> New
>
> Bug description:
> Cairo-Dock crashed and restarted while my whole band width was used up
> by another process. The relevent part of xsession-errors is attached.
> It says that the applet 'weather' may be the culprit.
>
> I use a recent Bazaar version and it's the second time I see such a
> crash. In both occasions the band width was used up by another
> process.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~cairo-dock-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~cairo-dock-team
> More help : https://help.launchpad.net/ListHelp
>

As a matter of fact, this bug shows up so infrequently that I doubt I could catch it with ddd. The CMAKE flag seems better.

Isn't the crash because cURL is freed before it's used in cd_warning()? I mean the following lines in function cd_weather_get_distant_data() in weather/src/applet-read-data.c:

cForecastData = cairo_dock_get_url_data (cURL, &erreur)
g_free (cURL);
if (erreur != NULL)
{
cd_warning ("while downloading forecast data:\n%s -> %s", cURL, erreur->message);
...
...
cForecastData = cairo_dock_get_url_data (cURL, &erreur);
g_free (cURL);
if (erreur != NULL)
{
cd_warning ("while downloading forecast data:\n%s -> %s", cURL, erreur->message);

Well done :)
It's should be better on rev 1966 => http://bazaar.launchpad.net/~cairo-dock-team/cairo-dock-plug-ins/plug-ins/revision/1966

Unfortunately, it isn't fixed yet. It occurred again a few minutes ago, complaining about d_weather_reset_weather_data in cd_weather_update_from_data, as before.

Just a guess:

The function cd_weather_update_from_data() is used in cd_weather_launch_periodic_task() in weather/src/applet-read-data.c:

myData.pTask = cairo_dock_new_task_full (myConfig.iCheckInterval,
(CairoDockGetDataAsyncFunc) cd_weather_get_distant_data,
(CairoDockUpdateSyncFunc) cd_weather_update_from_data,
(GFreeFunc) _free_shared_memory,
pSharedMemory);

_free_shared_memory(), which includes cd_weather_reset_weather_data (&pSharedMemory->wdata), is called there. So, perhaps cd_weather_reset_weather_data (&pSharedMemory->wdata) should be removed from cd_weather_update_from_data()?

This bug was fixed in the package cairo-dock-plug-ins - 2.3.0~2-0ubuntu1

---------------
cairo-dock-plug-ins (2.3.0~2-0ubuntu1) oneiric; urgency=low

  * New upstream release. (LP: #786105)
  * Upstream ChangeLog:
   - Fixed a typo in CMakeLists.txt about Ruby interface
   - CMakeLists.txt: Added the status of applets (stable / unstable
      / unsupported) to help packagers to not include unstable or
      unsupported applets on Cairo-Dock packages for stable distributions
  * debian/patches:
   - Added two upstream's patches:
    + to avoid a crash of u1sdtool (dnd2share)
    + to prevent a crash with Weather (LP: #788437)
  * debian/control:
   - Removed libgvfscommon-dev (not used and no longer available)
 -- Matthieu Baerts (matttbe) <email address hidden> Mon, 06 Jun 2011 12:09:47 +0200

Please read my last comment above. After I removed cd_weather_reset_weather_data (&pSharedMemory->wdata) from cd_weather_update_from_data(), I've seen no crash.

@Tsu Jan: Yes, I know but it was a bit too late...
It should be better now with the latest rev ;)