Oups. I replied only to michi7x7.

So here is the result if I use Glib Thread

---------- Forwarded message ----------
From: Fabian Jacquet <[email protected]>
Date: Thu, Apr 1, 2010 at 12:33
Subject: Re: ustring memory leak
To: michi7x7 <[email protected]>


Right.


Here is the std::cout
Leak of 118784/1000 or 118
Leak of 102400/1000 or 102

Leak of 0/1000 or 0
Leak of 0/1000 or 0
Leak of 0/1000 or 0
Leak of 0/1000 or 0

I supose that the Glib-Thread de-allocate something.
We don't want to use Glib-Thread everywhere because we have a lot of code
already in use.
Is it possible to call a method which will de-allocate Glib thread objects
at the end of our "Windows threads"?

On Thu, Apr 1, 2010 at 11:36, michi7x7 <[email protected]> wrote:

>  What happens if you use Glib-Threads instead of the Windows-API?
>
> Glib::Thread* const thread = Glib::Thread::create(sigc::ptr_fun(&thrd),
> true);
> thread->join();
>
>
> Hello,
>
> I have a memory leak using ustring under windows.
> I reproduced it with this code:
>
> #include "Windows.h"
>>
>> #include <glibmm/ustring.h>
>> #include <glibmm.h>
>> #include <iostream>
>> #include <Psapi.h>
>>
>> DWORD WINAPI thrd(LPVOID param)
>> {
>>     Glib::ustring u = "test";
>>     int i;
>>     if(u=="test")
>>         i = 0;
>>
>>     return 0;
>> }
>>
>> size_t GetMemory()
>> {
>>     PROCESS_MEMORY_COUNTERS c;
>>     if(GetProcessMemoryInfo(GetCurrentProcess(), &c, sizeof(c)))
>>     {
>>         return c.WorkingSetSize;
>>     }
>>     else
>>     {
>>         return 0;
>>     }
>> }
>>
>> int _tmain(int argc, _TCHAR* argv[])
>> {
>>     if(!Glib::thread_supported())
>>         Glib::thread_init();
>>
>>     int i = 0;
>>     size_t lastMem = GetMemory();
>>     int group = 1000;
>>     do{
>>         HANDLE h = CreateThread(NULL, NULL, thrd, NULL, NULL, NULL);
>>         WaitForSingleObject(h, INFINITE);
>>         CloseHandle(h);
>>
>>         if(i++ > group)
>>         {
>>             Sleep(500);
>>             size_t currentMemory = GetMemory();
>>             if(currentMemory > 0)
>>             {
>>                 size_t diff = currentMemory - lastMem;
>>                 std::cout << "Leak of " << diff << "/" << group << " or "
>> << diff/group << std::endl;
>>                 i = 0;
>>                 lastMem = currentMemory;
>>             }
>>             else
>>             {
>>                 std::cout << "No memory info" << std::endl;
>>             }
>>         }
>>     }while(1);
>>
>>     return 0;
>> }
>>
>
> Here is the std::cout
>
> Leak of 2494464/1000 or 2494
> Leak of 2420736/1000 or 2420
> Leak of 2375680/1000 or 2375
> Leak of 2379776/1000 or 2379
> Leak of 2375680/1000 or 2375
> Leak of 2379776/1000 or 2379
> Leak of 2379776/1000 or 2379
> ...
>
> So here we have a leak of about 2379 bytes for each thread.
>
>
> Here is the std::out if I remove following code
>
>>     if(!Glib::thread_supported())
>>
>          Glib::thread_init();
>>
>
> Leak of 348160/1000 or 348
> Leak of 106496/1000 or 106
> Leak of 0/1000 or 0
> Leak of 0/1000 or 0
> Leak of 0/1000 or 0
> Leak of 0/1000 or 0
> Leak of 0/1000 or 0
> ...
>
>
> We use Glib::thread_init() because we had some crashes on multi thread with
> ustring. It was not a problem of variable protection, the crash happened
> when some threads used different ustring. Typically, if we parse different
> XML with libxml in different thread, we had crash on an ustring compare. The
> Glib::thread_init() resolved the crash.
>
> If you want a sample of the crash problem, I can send it to you. Maybe we
> don't have to use Glib::thread_init().
>
>
> Thank you very much if somebody can help.
>
> Best regards.
>
>
>
> _______________________________________________
> gtkmm-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to