Menu

#213 bufferevent_free() deadlock again - test code

For_2.0
open
nobody
8
2011-04-21
2011-01-10
Yoon-ho Kim
No

Continueing the issue that I posted a week ago(post id 3151160), I made a test program which will show you the deadlock case.
If you have any interest, compile the test codes to get two executables. One is "testsv" the server, the other is "testcl" the client.
First, execute the "testsv".
./testsv
and in another shell you execute "testcl" several time like this.
./testcl < some_big_text_file

The testsv process is expected to terminate cleanly if you send SIGTERM or SIGINT.
But if it is stuck in deadlock, you need to kill it only with SIGKILL.

Test environment:
libevent version : 2.0.10-stable compiled with gcc 4.1.2 with CFLAGS="-g -O2"
operating system: CentOS 5.5 with kernel 2.6.18-194.26.1.el5 and libc 2.5-49.el5_5.7
hardware: CPU: 1x Intel Xeon X3320 2.50 GHz with 3Mb cache; MEM: 2Gb

If no feed back, I will be working on dirty fix to get my job done. If that fix turns out to be useful, I will let you know.

Discussion

  • Yoon-ho Kim

    Yoon-ho Kim - 2011-01-10
     
  • Yoon-ho Kim

    Yoon-ho Kim - 2011-01-12
     
  • Yoon-ho Kim

    Yoon-ho Kim - 2011-01-12

    Hi, libevent lovers!

    Without no comments about this from anyone, I finaly worked out a dirty fix.
    For your curiosity(If any), I attached a patch file.

    In the patch, I waned to present three key points:
    1. de-couple refcounting and locking bufferevent object.
    2. delete read/write events without locking bufferevent.
    3. allow defered user callback know that their 'ctx' is already freed.

    I did not considered many aspects. So this patch may not be appropriate to your concept.
    What I considered was only the socket based bufferevent and openssl bufferevent which have socket based bufferevent as its underlying bufferevent.

     
  • Nick Mathewson

    Nick Mathewson - 2011-04-21
    • priority: 5 --> 8
     

Log in to post a comment.