mainGnuTLS - Support: sr #107775, GnuTLS 3.0.0 causes segfault

 
 

sr #107775: GnuTLS 3.0.0 causes segfault

Submitter:  Jan Steffens <heftig>
Submitted:  Mon 15 Aug 2011 03:26:26 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  In Progress
Privacy:  Public Assigned to:  nmav
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 24 Sep 2011 09:05:40 PM UTC, comment #20: 

Thanks, that seems to fix all my problems for good.

Anonymous
Fri 23 Sep 2011 09:43:55 AM UTC, comment #19: 

Could you check the latest master without the patch? I've solved the problem differently (the patch wasn't entirely correct).

Nikos Mavrogiannopoulos <nmav>
Group administrator
Fri 23 Sep 2011 09:28:59 AM UTC, comment #18: 

With that patch applied ontop of latest git master, I can successfully connect, thanks.

However, after ~2 seconds, the following happens:

Program received signal SIGSEGV, Segmentation fault.
0xb7c18e1a in ?? () from /lib/libc.so.6
(gdb) bt full
#0  0xb7c18e1a in ?? () from /lib/libc.so.6
No symbol table info available.
#1  0xb7c1c37d in free () from /lib/libc.so.6
No symbol table info available.
#2  0xb7a4a080 in remove_front (buf=0x8116b6c) at gnutls_mbuffers.c:224
        bufel = 0x830f348
#3  0xb7a4a12e in _mbuffer_head_remove_bytes (buf=0x8116b6c, bytes=6549) at gnutls_mbuffers.c:257
        left = 0
        bufel = 0x830f348
        next = 0x0
        ret = 0
#4  0xb7a4721b in _gnutls_recv_in_buffers (session=0x81163e0, type=GNUTLS_APPLICATION_DATA,
    htype=4294967295) at gnutls_record.c:1003
        packet_sequence = 0x82b1138
        ciphertext = 0x830f381 "̚\307΄\300r\205\037\bY\244!]yC\316\071\263#\f0䜞\336\374wa9-\274\360\302#\215\246i\304@Ww\325\071\037\352\377_\331\361\357\241H\217tK\227\177\274\024\221\376\307\331\370\337\276wx\257\371\273\364\277E\370?\375\355/`^t\205T\261\032\351\367c\270~\315\373\325\333\022\376\016\031\215\245\343\367\227\033\336/\374\317\036\261`<\237\247iM\264X\360\252\031\373\257\067\371\271P\301\323\026I\203'\a\216\032\062\264\347_\177w\272B\367\274\r\215\177\217\331Kghe\316ſSt\001\271>,0T,r\347\371\221\232\065\275\225\367\306L\375u}\207\t\244\372[\026W\264\374\034\001\376D\365\330t\037"...
        bufel = 0x830f348
        decrypted = 0x830ab10
        ret = 8886
        empty_packet = 0
        record_params = 0x82b10b8
        record_state = 0x82b10cc
        record = {header_size = 5, version = "\003\001", sequence = {
            i = "\000\000\000\000\000\000\000"}, length = 6544, packet_size = 6549,
          type = GNUTLS_APPLICATION_DATA, epoch = 0, v2 = 0}
#5  0xb7a477aa in _gnutls_recv_int (session=0x81163e0, type=GNUTLS_APPLICATION_DATA,
---Type <return> to continue, or q <return> to quit---
    htype=4294967295, data=0xbfffeddc "\002", data_size=1023, seq=0x0) at gnutls_record.c:1165
        ret = 0
#6  0xb7a478a3 in gnutls_record_recv (session=0x81163e0, data=0xbfffeddc, data_size=1023)
    at gnutls_record.c:1238
No locals.
#7  0xb7fb279f in ?? () from /usr/lib/libloudmouth-1.so.0
No symbol table info available.
#8  0xb7fb41f7 in ?? () from /usr/lib/libloudmouth-1.so.0
No symbol table info available.
#9  0xb7f3f6ce in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#10 0xb7ef9c4f in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#11 0xb7efa3b0 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#12 0xb7efa6da in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#13 0x08052316 in main ()
No symbol table info available.

Anonymous
Thu 22 Sep 2011 11:56:32 AM UTC, comment #17: 

I see. It seems the (de)compression code is not working properly in 3.0.x. Consider disabling it temporarily until the next release. I attach a quick fix in case compression is crucial for you, but I need to verify there are no side-effects.


(file #24013)

Anonymous
Thu 22 Sep 2011 11:43:56 AM UTC, comment #16: 

Nope, the patch didn't really work, the current packet is send fine, but stuff still fails shortly thereafter (one of the cases was local connection close without an alert, the other was the remote closing the connection without an alert).

Thanks for the --priority hint, that hits the same problem on the affected box. Attached is the output of ' gnutls-cli 217.10.10.194 --port 5223 --priority NORMAL:+COMP-DEFLATE --debug 1000' ('1000' is just "some large value").

(file #24012)

Anonymous
Thu 22 Sep 2011 11:19:37 AM UTC, comment #15: 

Use gnutls-cli --priority NORMAL:+COMP-DEFLATE. Does your patch fix the issue for you?

Anonymous
Thu 22 Sep 2011 10:46:09 AM UTC, comment #14: 

Attached are pcap files for vanilla gnutls 3.0.3 (before the bug fix where a negative value was assigned to a unsigned variable, but the error we are looking into now happens before that) and two version of my ugly and apparently wrong attempt to fix this.

I also did trace of 'gnutls-cli 217.10.10.194 --port 5223', exported them as text and diff't it to vanilla gnutls. mcabber proposes DEFLATE while gnutls-cli doesn't and mcabber sends a cert_type extension while gnutls_cli instead sends a server_name extension. Can one somehow make gnutls-cli to propose deflate, too?

(file #24008, file #24009, file #24010, file #24011)

Anonymous
Tue 20 Sep 2011 01:49:48 PM UTC, comment #13: 

Really strange. Could you send me a tcpdump capture of that transaction? Is there any way for me to reproduce that?


Anonymous
Tue 20 Sep 2011 11:15:12 AM UTC, comment #12: 

Oh, in _gnutls_encrypt(), cur_record_params has different content than params (which is what is passed to plaintext2compressed). cur_record_params->compression_algorithm == GNUTLS_COMP_DEFLATE while params has GNUTLS_COMP_NULL.

Doing "cur_record_params = params;" makes gnutls close the connection, doing "params = cur_record_params;" in _gnutls_encrypt() makes the other end close the connection, but at least the current call to _gnutls_encrypt() doesn't fail in either case. And no, in neither case is an Alert send. :(


Anonymous
Tue 20 Sep 2011 10:56:17 AM UTC, comment #11: 

(Sorry for the slow reply)

Yeah, the compression fails. _gnutls_send_int() calls _gnutls_encrypt() calls _gnutls_m_plaintext2compressed() calls _gnutls_compress(). However, params->write.compression_state is a NULL pointer, so the first argument to _gnutls_compress() is NULL.

Any hint where to look next? Why is this trying to compress something with GNUTLS_COMP_NULL?

(gdb) bt
#0  _gnutls_compress (handle=0x0, plain=0x8fbf504 "\020", plain_size=460, compressed=0xbffcef28,
    max_comp_size=18432) at gnutls_compress.c:409
#1  0xb71e199a in _gnutls_m_plaintext2compressed (session=0x8c04570, compressed=0xbffcef64,
    plaintext=0xbffcef6c, params=0x8fbfd90) at gnutls_compress.c:46
#2  0xb71e2953 in _gnutls_encrypt (session=0x8c04570, headers=0xbffcefef "\026\003\001",
    headers_size=5, data=0x8fbf504 "\020", data_size=460, ciphertext=0x8df2bb4 "",
    ciphertext_size=2843, type=GNUTLS_HANDSHAKE, params=0x8fbfd90) at gnutls_cipher.c:109
#3  0xb71df9c7 in _gnutls_send_int (session=0x8c04570, type=GNUTLS_HANDSHAKE,
    htype=GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE, epoch_rel=0, _data=0x8fbf504, data_size=460,
    mflags=0) at gnutls_record.c:432
#4  0xb71e5a2f in _gnutls_handshake_io_write_flush (session=0x8c04570) at gnutls_buffers.c:655
#5  0xb71e9b6e in _gnutls_send_handshake (session=0x8c04570, bufel=0x8fbeab8,
    type=GNUTLS_HANDSHAKE_FINISHED) at gnutls_handshake.c:1122
#6  0xb71e8d04 in _gnutls_send_finished (session=0x8c04570, again=0) at gnutls_handshake.c:656
#7  0xb71ecf41 in _gnutls_send_handshake_final (session=0x8c04570, init=1)
    at gnutls_handshake.c:2594
#8  0xb71edb29 in _gnutls_handshake_common (session=0x8c04570) at gnutls_handshake.c:2816
#9  0xb71ec393 in gnutls_handshake (session=0x8c04570) at gnutls_handshake.c:2336
#10 0xb774c428 in ?? () from /usr/lib/libloudmouth-1.so.0
#11 0xb774df71 in ?? () from /usr/lib/libloudmouth-1.so.0
#12 0xb774e6f9 in ?? () from /usr/lib/libloudmouth-1.so.0
#13 0xb774f0d8 in ?? () from /usr/lib/libloudmouth-1.so.0
#14 0xb76d96ce in ?? () from /usr/lib/libglib-2.0.so.0
#15 0xb7693c4f in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#16 0xb76943b0 in ?? () from /usr/lib/libglib-2.0.so.0
#17 0xb76946da in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#18 0x08052316 in main ()
(gdb) frame 1
#1  0xb71e199a in _gnutls_m_plaintext2compressed (session=0x8c04570, compressed=0xbffcef64,
    plaintext=0xbffcef6c, params=0x8fbfd90) at gnutls_compress.c:46
46   size =
(gdb) print *params
$10 = {epoch = 0, initialized = 1, cipher_algorithm = GNUTLS_CIPHER_NULL,
  mac_algorithm = GNUTLS_MAC_NULL, compression_algorithm = GNUTLS_COMP_NULL, read = {mac_secret = {
      data = 0x0, size = 0}, IV = {data = 0x0, size = 0}, key = {data = 0x0, size = 0},
    cipher_state = {cipher = {handle = 0x0, encrypt = 0, decrypt = 0, auth = 0, tag = 0, setiv = 0,
        deinit = 0, tag_size = 0, is_aead = 0}, mac = {algorithm = GNUTLS_MAC_UNKNOWN, key = 0x0,
        keysize = 0, hash = 0, copy = 0, reset = 0, output = 0, deinit = 0, handle = 0x0},
      is_mac = 0, ssl_hmac = 0, tag_size = 0}, compression_state = 0x0, sequence_number = {
      i = "\000\000\000\000\000\000\000\003"}}, write = {mac_secret = {data = 0x0, size = 0}, IV = {
      data = 0x0, size = 0}, key = {data = 0x0, size = 0}, cipher_state = {cipher = {handle = 0x0,
        encrypt = 0, decrypt = 0, auth = 0, tag = 0, setiv = 0, deinit = 0, tag_size = 0,
        is_aead = 0}, mac = {algorithm = GNUTLS_MAC_UNKNOWN, key = 0x0, keysize = 0, hash = 0,
        copy = 0, reset = 0, output = 0, deinit = 0, handle = 0x0}, is_mac = 0, ssl_hmac = 0,
      tag_size = 0}, compression_state = 0x0, sequence_number = {
      i = "\000\000\000\000\000\000\000\001"}}, usage_cnt = 2}

Anonymous
Tue 30 Aug 2011 01:51:45 PM UTC, comment #10: 

Thank you for finding it out. I've committed a fix in master. The compression failed is pretty awkward. Does zlib return an error?

Nikos Mavrogiannopoulos <nmav>
Group administrator
Tue 30 Aug 2011 11:59:40 AM UTC, comment #9: 

I figured out where those wrong values come from (well, kinda).

In _gnutls_send_int, cipher_size is a size_t. It is assigned the result from _gnutls_encrypt() in line 437. However, this function returns an int where negative values are used for errors. Line 440 then indeed checks if (cipher_size <= 0), however, since size_t is unsigned, this would only be true if cipher_size == 0.

This code then goes on and tries to send garbage.

Patch for this hopefully is attached, however I'm not sure if the size_t type is required for other places in this code. Someone with a clue should check carefully and perhaps split cipher_size up into two different variables. It might also make sense to use int instead of ssize_t. Dunno.

Now, I only have to figure out why I get GNUTLS_E_COMPRESSION_FAILED (-27) immediately after the handshake...

(file #23906)

Anonymous
Mon 22 Aug 2011 11:41:43 AM UTC, comment #8: 

To attach a file check below the discussion.

Nikos Mavrogiannopoulos <nmav>
Group administrator
Mon 22 Aug 2011 07:56:44 AM UTC, comment #7: 

Hi,

I can reproduce this problem with mcabber. strace says:

connect(3, {sa_family=AF_INET, sin_port=htons(5223), sin_addr=inet_addr("217.10.10.194")}, 16) = -1 EINPROGRESS (Operation now in progress)
[...]
poll([{fd=3, events=POLLOUT}, {fd=0, events=POLLIN|POLLPRI}], 2, -1) = 1 ([{fd=3, revents=POLLOUT}])
open("/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 5
[...]
writev(3, [{"\26\3\0\0\276\1\0\0\272\3\3NQ\373C\370+\25\361\334F\0\321y!\6#\5|1}\34"..., 195}], 1) = 195
recv(3, "\26\3\1\0001", 5, 0)           = 5
recv(3, "\2\0\0-\3\1NQ\373C\374\211v\347\276y(\r\302\22\236\v\244K\233\217\305\35;\372\252\264"..., 49, 0) = 49
recv(3, "\26\3\1\23b", 5, 0)            = 5
recv(3, "\v\0\23^\0\23[\0\6\0050\202\6\0010\202\3\351\240\3\2\1\2\2\3\0\267\3610\r\6\t"..., 4962, 0) = 1389
recv(3, "\16\214\376\217<|\303}+W'1\320A\332\256)\241\315h\23\257\260\31\250|\305\366\212\365\203\352"..., 3573, 0) = 1448
recv(3, "X>\351\224+\221P\207\33\326^\326\214\314\367\17\20\fRN\320\26a\345\345\nl\277\27\307rF"..., 2125, 0) = 1448
recv(3, "crl04\6\t`\206H\1\206\370B\1\10\4'\26%http://www.c"..., 677, 0) = 677
recv(3, "\26\3\1\0\4", 5, 0)            = 5
recv(3, "\16\0\0\0", 4, 0)              = 4
[...]
writev(3, [{"", 4294967269}, {"", 4294967269}, {"\26\3\1\0\360sI-\315\33\262$5\343\22\240\2\345\201\332\306\210?\303\224\215\266\252`|\36R"..., 245}], 3) = -1 EINVAL (Invalid argument)
shutdown(3, SHUT_RDWR)                  = 0
close(3)                                = 0

The length argument to writev() is (unsigned int)-26.

Valgrind only has complaints about libidn (read of size 4 with offset 4 in an allocation of size 7). This can't cause any corruption. Then comes the writev():

==17779== Syscall param writev(vector[...]) points to unaddressable byte(s)
==17779==    at 0x43C1ADE: writev (in /lib/libc-2.14.so)
==17779==  Address 0x6dd6e67 is 0 bytes after a block of size 2,895 alloc'd
==17779==    at 0x4026416: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17779==    by 0x44F271F: ??? (in /usr/lib/libgnutls.so.28.0.1)
==17779==    by 0x44EE7CA: _gnutls_send_int (in /usr/lib/libgnutls.so.28.0.1)
==17779==    by 0x44F47E6: ??? (in /usr/lib/libgnutls.so.28.0.1)
==17779==    by 0x44F668C: ??? (in /usr/lib/libgnutls.so.28.0.1)
==17779==    by 0x44F6B2C: ??? (in /usr/lib/libgnutls.so.28.0.1)
==17779==    by 0x44F8C4F: ??? (in /usr/lib/libgnutls.so.28.0.1)
==17779==    by 0x44FA558: gnutls_handshake (in /usr/lib/libgnutls.so.28.0.1)
==17779==    by 0x4055427: ??? (in /usr/lib/libloudmouth-1.so.0.1.0)
==17779==    by 0x4056F70: ??? (in /usr/lib/libloudmouth-1.so.0.1.0)
==17779==    by 0x40576F8: ??? (in /usr/lib/libloudmouth-1.so.0.1.0)
==17779==    by 0x40580D7: ??? (in /usr/lib/libloudmouth-1.so.0.1.0)

All the packages used are archlinux x86 stock ones. I'd be happy about any hints on how I can debug this further.

P.S.: How do I attach files?

Anonymous
Wed 17 Aug 2011 06:46:52 AM UTC, comment #6: 

Nikos Mavrogiannopoulos wrote:

> The attached log shows there is a problem in the application in
> whole. Why do you get the Source and destination overlap in
> memcpy()? At least in the GnuTLS case, when this message is printed
> memmove() was being called indicating that something is not right.


Hello,
This reminds me of <http://bugs.debian.org/619963> a glibc header bug triggered by gcc-4.6.
cu andreas

Andreas Metzler <ametzler>
Tue 16 Aug 2011 09:06:46 PM UTC, comment #5: 

Than I don't know how I can help you, unless you can provide a minimal program that reproduces the issue you see. Try also executing gnutls-cli and gnutls-serv. If they have no issues in your system then it is likely that there is a memory corruption in your application.

Nikos Mavrogiannopoulos <nmav>
Group administrator
Tue 16 Aug 2011 06:53:37 PM UTC, comment #4: 

I don't know why, sorry.

This system runs Arch Linux x86_64. I did recompile gnutls and telepathy-gabble using "-O0 -g2" to help debug this.

Jan Steffens <heftig>
Mon 15 Aug 2011 08:23:39 PM UTC, comment #3: 

It doesn't on my system, thus I need more information to reproduce it. The attached log shows there is a problem in the application in whole. Why do you get the Source and destination overlap in memcpy()? At least in the GnuTLS case, when this message is printed memmove() was being called indicating that something is not right.


Nikos Mavrogiannopoulos <nmav>
Group administrator
Mon 15 Aug 2011 07:54:01 PM UTC, comment #2: 

Seems to occur on most attempts to connect.

Here's a valgrind log. I killed it because it seriously thrashed my laptop, but it did get to a warning about the crashing g_memdup.

(file #23811)

Jan Steffens <heftig>
Mon 15 Aug 2011 06:31:49 AM UTC, comment #1: 

Is there a way to reproduce this issue? It might be memory corruption, have you tried valgrind?

Nikos Mavrogiannopoulos <nmav>
Group administrator
Mon 15 Aug 2011 03:26:26 AM UTC, original submission:  

telepathy-gabble segfaults when used with GnuTLS 3.0.0.

Backtrace:
#0  0x00007ffff56dc7f0 in ?? () from /lib/libc.so.6
#1  0x00007ffff56d6735 in memmove () from /lib/libc.so.6
#2  0x00007ffff5a17999 in g_memdup () from /usr/lib/libglib-2.0.so.0
#3  0x00000000004e3899 in wocky_tls_session_push_func (user_data=0x7e01a0, buffer=0x8921b0, count=4294967269) at wocky-tls.c:1192
#4  0x00007ffff6e800c5 in _gnutls_writev_emu (session=0x88f9d0, fd=0x7e01a0, giovec=0x7fffffffd710, giovec_cnt=3) at gnutls_buffers.c:322
#5  0x00007ffff6e8016e in _gnutls_writev (session=0x88f9d0, giovec=0x7fffffffd710, giovec_cnt=3) at gnutls_buffers.c:349
#6  0x00007ffff6e808de in _gnutls_io_write_flush (session=0x88f9d0) at gnutls_buffers.c:564
#7  0x00007ffff6e80e02 in _gnutls_handshake_io_write_flush (session=0x88f9d0) at gnutls_buffers.c:679
#8  0x00007ffff6e85947 in _gnutls_send_handshake (session=0x88f9d0, bufel=0xb40440, type=GNUTLS_HANDSHAKE_FINISHED) at gnutls_handshake.c:1133
#9  0x00007ffff6e84916 in _gnutls_send_finished (session=0x88f9d0, again=0) at gnutls_handshake.c:667
#10 0x00007ffff6e8925b in _gnutls_send_handshake_final (session=0x88f9d0, init=1) at gnutls_handshake.c:2600
#11 0x00007ffff6e89f02 in _gnutls_handshake_common (session=0x88f9d0) at gnutls_handshake.c:2822
#12 0x00007ffff6e885e4 in gnutls_handshake (session=0x88f9d0) at gnutls_handshake.c:2342
#13 0x00000000004e1a3e in wocky_tls_session_try_operation (session=0x7e01a0, operation=WOCKY_TLS_OP_READ) at wocky-tls.c:386
#14 0x00000000004e35a9 in wocky_tls_session_read_ready (object=0x818c90, result=0x85c920, user_data=0x7e01a0) at wocky-tls.c:1111
#15 0x00007ffff6578929 in ?? () from /usr/lib/libgio-2.0.so.0
#16 0x00007ffff659010c in ?? () from /usr/lib/libgio-2.0.so.0
#17 0x00007ffff59fa29d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#18 0x00007ffff59faa78 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0x00007ffff59fb0ba in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#20 0x00007ffff6bbe04f in tp_run_connection_manager () from /usr/lib/libtelepathy-glib.so.0
#21 0x0000000000431e81 in gabble_main (argc=1, argv=0x7fffffffdea8) at gabble.c:177
#22 0x0000000000431b09 in main (argc=1, argv=0x7fffffffdea8) at main.c:28

Look at that count=4294967269 buffer length (#3), that can't be right. Of
the three giovecs used, the first two have 4294967269 length, the
third one has a more sane 53.

Jan Steffens <heftig>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #24013:  patch.txt added by None (2KiB - text/plain - compression quick fix)
file #24012:  debug_output added by None (10KiB - application/octet-stream - gnutls_cli debug output)
file #24008:  vanilla-gnutls.pcap added by None (6KiB - application/octet-stream - pcap file of mcabber 0.10.1 with gnutls 3.0.3)
file #24009:  cur_params=params.pcap added by None (7KiB - application/octet-stream - pcap file of mcabber 0.10.1 with gnutls 3.0.3)
file #24010:  params=cur_params.pcap added by None (8KiB - application/octet-stream - pcap file of mcabber 0.10.1 with gnutls 3.0.3)
file #24011:  patch added by None (1KiB - application/octet-stream - pcap file of mcabber 0.10.1 with gnutls 3.0.3)
file #23906:  patch added by None (439B - application/octet-stream)
file #23811:  valgrind.log added by heftig (76KiB - text/x-log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Posted a comment)
  • -email is unavailable- added by heftig (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-28 nmav Open/ClosedOpen Closed
    2011-09-22 None Attached File- Added patch.txt, #24013
    2011-09-22 None Attached File- Added debug_output, #24012
    2011-09-22 None Attached File- Added vanilla-gnutls.pcap, #24008
        Attached File- Added cur_params=params.pcap, #24009
        Attached File- Added params=cur_params.pcap, #24010
        Attached File- Added patch, #24011
    2011-08-30 nmav StatusNeed Info In Progress
    2011-08-30 None Attached File- Added patch, #23906
    2011-08-17 ametzler Carbon-CopyRemoved 20807 -
    2011-08-15 heftig Attached File- Added valgrind.log, #23811
    2011-08-15 nmav StatusNone Need Info
        Assigned toNone nmav

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code