Bug 705827 – Segmentation fault due to memory leak in ucontext coroutine

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 705827 - Segmentation fault due to memory leak in ucontext coroutine


Summary:	Segmentation fault due to memory leak in ucontext coroutine


Status:	RESOLVED FIXED

Product:	gtk-vnc
Classification:	Other
Component:	general
Version:	0.5.x
Hardware:	Other Linux

Importance:	Normal major
Target Milestone:	---
Assigned To:	gtk-vnc-maint
QA Contact:	gtk-vnc-maint

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2013-08-12 11:05 UTC by Artem Rusanov
Modified:	2013-09-18 11:23 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
Test to reproduce bug (865 bytes, text/x-csrc) 2013-08-12 11:05 UTC, Artem Rusanov	Details

Description Artem Rusanov 2013-08-12 11:05:55 UTC

Created attachment 251333 [details]
Test to reproduce bug

Ucontext coroutine have problems with stability, gthread coroutine is ok.
To reproduce just run following test, in some seconds you will get segfault.

Program received signal SIGSEGV, Segmentation fault.
0xf786a228 in ?? () from /lib/libglib-2.0.so.0
(gdb) bt

+ Trace 232375

#0 ??
from /lib/libglib-2.0.so.0
#1 IA__g_idle_add_full
at /build/buildd-glib2.0_2.24.2-1-i386-AScyie/glib2.0-2.24.2/glib/gmain.c line 4128
#2 IA__g_idle_add
at /build/buildd-glib2.0_2.24.2-1-i386-AScyie/glib2.0-2.24.2/glib/gmain.c line 4154
#3 vnc_connection_coroutine
at vncconnection.c line 5195
#4 coroutine_trampoline
at coroutine_ucontext.c line 52
#5 continuation_trampoline
at continuation.c line 43
#6 makecontext
from /lib/libc.so.6
#7 ??
from /lib/libc.so.6
#8 ??
from /usr/local/lib/libgvnc-1.0.so.0

Comment 1 Daniel P. Berrange 2013-09-13 10:26:58 UTC

I'm not seeing any crash from this demo program, but I am seeing it massively leak memory. I suspect it'll eventually crash once it has exhausted all my 24 GB of ram and swap, but i don't fancy waiting to see that :-) The memory leak is something I'll investigate....

Comment 2 Artem Rusanov 2013-09-13 11:00:55 UTC

Yes, more memory - more time before crash. I found this problem with 512M computer. It looks like something wrong with stack, during run stack grows with no limitation, system  continuously increases size, and finally no more memory to continue...

Comment 3 Daniel P. Berrange 2013-09-13 11:21:47 UTC

This will be fixed in two patches

commit 49fbd957cb686ff3f9c31923ff17a9529edd9c13
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Fri Sep 13 12:06:57 2013 +0100

    Free coroutine stack when releasing coroutine
    
    The coroutine_init function mmap's a stack for the
    ucontext coroutine, but nothing ever munmaps it.
    
    Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

commit b3963416e22382a1fa0ef2d4196f421ef6aee56d
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Fri Sep 13 12:05:55 2013 +0100

    Abort if mmap of coroutine stack fails
    
    If we fail to mmap the stack, abort the processs rather
    than returning an error. This is standard practice in
    glib apps, and the caller was not checking the
    coroutine_init() return code leading to memory corruption.
    
    Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

though I've not pushed to git yet.

Comment 4 Daniel P. Berrange 2013-09-18 11:23:59 UTC

Fixed in the 0.5.3 release