Search Results

Search found 11 results on 1 pages for 'longjmp'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 1/1 | 1 

  • In C: sending func pointers, calling the func with it, playing with EIP, jum_buf and longjmp

    - by Yonatan
    Hello Internet ! I need to make sure i understand some basic stuff first: 1. how do i pass function A as a parameter to function B? 2. how do i call function A from inside B ? now for the big whammy: I'm trying to do something along the lines of this: jmp_buf buf; buf.__jmpbuf[JB_PC] = functionA; longjmp(buf,10); meaning that i want to use longjmp in order to go to a function. how should i do it ? thank you very much internet people ! Yonatan

    Read the article

  • What is weird about wrapping setjmp and longjmp?

    - by Max
    Hello. I am using setjmp and longjmp for the first time, and I ran across an issue that comes about when I wrap setjmp and longjmp. I boiled the code down to the following example: #include <stdio.h> #include <setjmp.h> jmp_buf jb; int mywrap_save() { int i = setjmp(jb); return i; } int mywrap_call() { longjmp(jb, 1); printf("this shouldn't appear\n"); } void example_wrap() { if (mywrap_save() == 0){ printf("wrap: try block\n"); mywrap_call(); } else { printf("wrap: catch block\n"); } } void example_non_wrap() { if (setjmp(jb) == 0){ printf("non_wrap: try block\n"); longjmp(jb, 1); } else { printf("non_wrap: catch block\n"); } } int main() { example_wrap(); example_non_wrap(); } Initially I thought example_wrap() and example_non_wrap() would behave the same. However, the result of running the program (GCC 4.4, Linux): wrap: try block non_wrap: try block non_wrap: catch block If I trace the program in gdb, I see that even though mywrap_save() returns 1, the else branch after returning is oddly ignored. Can anyone explain what is going on?

    Read the article

  • Problem with setjmp/longjmp

    - by user294732
    The code below is just not working. Can anybody point out why #define STACK_SIZE 1524 static void mt_allocate_stack(struct thread_struct *mythrd) { unsigned int sp = 0; void *stck; stck = (void *)malloc(STACK_SIZE); sp = (unsigned int)&((stck)); sp = sp + STACK_SIZE; while((sp % 8) != 0) sp--; #ifdef linux (mythrd->saved_state[0]).__jmpbuf[JB_BP] = (int)sp; (mythrd->saved_state[0]).__jmpbuf[JB_SP] = (int)sp-500; #endif } void mt_sched() { fprintf(stdout,"\n Inside the mt_sched"); fflush(stdout); if ( current_thread->state == NEW ) { if ( setjmp(current_thread->saved_state) == 0 ) { mt_allocate_stack(current_thread); fprintf(stdout,"\n Jumping to thread = %u",current_thread->thread_id); fflush(stdout); longjmp(current_thread->saved_state, 2); } else { new_fns(); } } } All I am trying to do is to run the new_fns() on a new stack. But is is showing segmentation fault at new_fns(). Can anybody point me out what's wrong.

    Read the article

  • How to properly siglongjmp out of signal handler?

    - by EpsilonVector
    Suppose I have the following code: In order to implement a context switch I activate ualarm and when it jumps to the handler it setjmp's the current context, and longjmps to the next, expecting to eventually return to the alarm handler and longjmped back into this context (the contexts are cycled through in a Round Robin). For this I need to keep SIGALRM unblocked in between alarm_handlers. I came up with the following code, which doesn't seem to work. What's wrong with it and what is the right way to do this? void alarm_handler(){ if(sigsetjmp(toc->threads[toc->RR_pointer].env, 0)){ ualarm(200, 0); signal(SIGALRM, alarm_handler); return; } get_next_context_number(toc->RR_pointer); //is a macro for (j=0; j<10; j++) printf("ALARM HANDLER\n"); siglongjmp(toc->threads[toc->RR_pointer].env, 1); }

    Read the article

  • What is the best way to save the environment from before an alarm handler goes off when the alarm do

    - by EpsilonVector
    I'm trying to implement user threads on a 2.4 Linux kernel (homework) and the trick for context switch seems to be using an alarm that goes off every x milliseconds and sends us to an alarm handler from which we can longjmp to the next thread. What I'm having difficulties with is figuring out how to save the environment to return to later. Basically I have an array of jmp_buffs, and every time a "context switch" using the alarm happens I want to save the previous context to the appropriate entry of the array and longjmp to the next one. However, just the fact that I need to do this from the event handler means that just using setjmp in the event handler won't give me exactly the kind of environment I want (as far as stack and program counter are involved) because the stack has the event handler call in it and the pc is in the event handler. I suppose I can look at the stack and alter it to fit my needs, but that feels a bit cumbersome. Another idea I had is to somehow pass the environment before the jump to event handler as a parameter to the event handler, but I can't figure out if this is possible. So I guess my question is- how do I do this right?

    Read the article

  • unable to install gems in ruby 1.8.7 2012.12 patchlevel 253 and gem 1.3.7

    - by bakyaraj
    * longjmp causes uninitialized stack frame *: /usr/bin/ruby terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xc372d0] /lib/tls/i686/cmov/libc.so.6(+0xe223a)[0xc3723a] /usr/bin/ruby[0x80577b9] /usr/bin/ruby[0x80577d5] /usr/bin/ruby(rb_thread_schedule+0x9fc)[0x80652ac] /usr/bin/ruby(rb_thread_kill+0x14)[0x8066c74] /usr/bin/ruby[0x806071d] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x806a290] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x806995b] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x8069d54] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x805df2d] /usr/bin/ruby[0x8069581] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x806a0eb] /usr/bin/ruby[0x805e630] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x806a715] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x805e58a] /usr/bin/ruby[0x805e4aa] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x80693f1] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x806a0eb] /usr/bin/ruby[0x805e630] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x806a0eb] /usr/bin/ruby[0x805e630] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601]

    Read the article

  • Fixing a multi-threaded pycurl crash.

    - by Rook
    If I run pycurl in a single thread everything works great. If I run pycurl in 2 threads python will access violate. The first thing I did was report the problem to pycurl, but the project died about 3 years ago so I'm not holding my breath. My (hackish) solution is to build a 2nd version of pycurl called "pycurl_thread" which will only be used by the 2nd thread. I downloaded the pycurl module from sourceforge and I made a total of 4 line changes. But python is still crashing. My guess is that even though this is a module with a different name (import pycurl_thread), its still sharing memory with the original module (import pycurl). How should I solve this problem? Changes in pycurl.c: initpycurl(void) to initpycurl_thread(void) and m = Py_InitModule3("pycurl", curl_methods, module_doc); to m = Py_InitModule3("pycurl_thread", curl_methods, module_doc); Changes in setup.py: PACKAGE = "pycurl" PY_PACKAGE = "curl" to PACKAGE = "pycurl_thread" PY_PACKAGE = "curl_thread" Here is the seg fault i'm getting. This is happening within the C function do_curl_perform(). *** longjmp causes uninitialized stack frame ***: python2.7 terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x37)[0x7f209421b537] /lib/libc.so.6(+0xff4c9)[0x7f209421b4c9] /lib/libc.so.6(__longjmp_chk+0x33)[0x7f209421b433] /usr/lib/libcurl.so.4(+0xe3a5)[0x7f20931da3a5] /lib/libpthread.so.0(+0xfb40)[0x7f209532eb40] /lib/libc.so.6(__poll+0x53)[0x7f20941f6203] /usr/lib/libcurl.so.4(Curl_socket_ready+0x116)[0x7f2093208876] /usr/lib/libcurl.so.4(+0x2faec)[0x7f20931fbaec] /usr/local/lib/python2.7/dist-packages/pycurl.so(+0x892b)[0x7f209342c92b] python2.7(PyEval_EvalFrameEx+0x58a1)[0x4adf81] python2.7(PyEval_EvalCodeEx+0x891)[0x4af7c1] python2.7(PyEval_EvalFrameEx+0x538b)[0x4ada6b] python2.7(PyEval_EvalFrameEx+0x65f9)[0x4aecd9]

    Read the article

  • GOTO still considered harmful?

    - by Kyle Cronin
    Everyone is aware of Dijkstra's Letters to the editor: go to statement considered harmful (also here .html transcript and here .pdf) and there has been a formidable push since that time to eschew the goto statement whenever possible. While it's possible to use goto to produce unmaintainable, sprawling code, it nevertheless remains in modern programming languages. Even the advanced continuation control structure in Scheme can be described as a sophisticated goto. What circumstances warrant the use of goto? When is it best to avoid? As a followup question: C provides a pair of functions, setjmp and longjmp, that provide the ability to goto not just within the current stack frame but within any of the calling frames. Should these be considered as dangerous as goto? More dangerous? Dijkstra himself regretted that title, of which he was not responsible for. At the end of EWD1308 (also here .pdf) he wrote: Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth. A well thought out classic paper about this topic, to be matched to that of Dijkstra, is Structured Programming with go to Statements (also here .pdf), by Donald E. Knuth. Reading both helps to reestablish context and a non-dogmatic understanding of the subject. In this paper, Dijkstra's opinion on this case is reported and is even more strong: Donald E. Knuth: I believe that by presenting such a view I am not in fact disagreeing sharply with Dijkstra's ideas, since he recently wrote the following: "Please don't fall into the trap of believing that I am terribly dogmatical about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!"

    Read the article

  • Unable to install rubygems in ubuntu 10.04

    - by loganathan
    I had installed the ruby 1.8.7 with patch level 253 successfully on my ubuntu 10.04, but while installing ruby gems I am facing the below error, can anybody help me on this. ruby -v ruby 1.8.7 (2010-04-19 patchlevel 253) [i686-linux], MBARI 0x8770, Ruby Enterprise Edition 2010.02 gem install mongrel *** longjmp causes uninitialized stack frame ***: /usr/bin/ruby terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0x3612d0] /lib/tls/i686/cmov/libc.so.6(+0xe223a)[0x36123a] /usr/bin/ruby[0x80577b9] /usr/bin/ruby[0x80577d5] /usr/bin/ruby(rb_thread_schedule+0x9fc)[0x80652ac] /usr/bin/ruby(rb_thread_kill+0x14)[0x8066c74] /usr/bin/ruby[0x806071d] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x806a290] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x806995b] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x8069d54] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x805df2d] /usr/bin/ruby[0x8069581] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x806a0eb] /usr/bin/ruby[0x805e630] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x806a715] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x805e58a] /usr/bin/ruby[0x805e4aa] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x80693f1] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x806a0eb] /usr/bin/ruby[0x805e630] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806a869] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x806a0eb] /usr/bin/ruby[0x805e630] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] /usr/bin/ruby[0x80608b9] /usr/bin/ruby[0x806aaa5] /usr/bin/ruby[0x805e48b] /usr/bin/ruby[0x805de52] /usr/bin/ruby[0x8060601] ======= Memory map: ======== 00110000-00112000 r-xp 00000000 08:06 3805677 /usr/lib/ruby/1.8/i686-linux/etc.so 00112000-00113000 r--p 00001000 08:06 3805677 /usr/lib/ruby/1.8/i686-linux/etc.so 00113000-00114000 rw-p 00002000 08:06 3805677 /usr/lib/ruby/1.8/i686-linux/etc.so 00114000-0012e000 r-xp 00000000 08:06 3805682 /usr/lib/ruby/1.8/i686-linux/syck.so 0012e000-0012f000 r--p 00019000 08:06 3805682 /usr/lib/ruby/1.8/i686-linux/syck.so 0012f000-00130000 rw-p 0001a000 08:06 3805682 /usr/lib/ruby/1.8/i686-linux/syck.so 00130000-00131000 r-xp 00000000 08:06 3805666 /usr/lib/ruby/1.8/i686-linux/fcntl.so 00131000-00132000 r--p 00000000 08:06 3805666 /usr/lib/ruby/1.8/i686-linux/fcntl.so 00132000-00133000 rw-p 00001000 08:06 3805666 /usr/lib/ruby/1.8/i686-linux/fcntl.so 00133000-00150000 r-xp 00000000 08:06 11403438 /lib/libgcc_s.so.1 00150000-00151000 r--p 0001c000 08:06 11403438 /lib/libgcc_s.so.1 00151000-00152000 rw-p 0001d000 08:06 11403438 /lib/libgcc_s.so.1 001e2000-00206000 r-xp 00000000 08:06 11403697 /lib/tls/i686/cmov/libm-2.11.1.so 00206000-00207000 r--p 00023000 08:06 11403697 /lib/tls/i686/cmov/libm-2.11.1.so 00207000-00208000 rw-p 00024000 08:06 11403697 /lib/tls/i686/cmov/libm-2.11.1.so 0024d000-00256000 r-xp 00000000 08:06 11403688 /lib/tls/i686/cmov/libcrypt-2.11.1.so 00256000-00257000 r--p 00008000 08:06 11403688 /lib/tls/i686/cmov/libcrypt-2.11.1.so 00257000-00258000 rw-p 00009000 08:06 11403688 /lib/tls/i686/cmov/libcrypt-2.11.1.so 00258000-0027f000 rw-p 00000000 00:00 0 0027f000-003d2000 r-xp 00000000 08:06 11403695 /lib/tls/i686/cmov/libc-2.11.1.so 003d2000-003d4000 r--p 00153000 08:06 11403695 /lib/tls/i686/cmov/libc-2.11.1.so 003d4000-003d5000 rw-p 00155000 08:06 11403695 /lib/tls/i686/cmov/libc-2.11.1.so 003d5000-003d8000 rw-p 00000000 00:00 0 0047e000-00488000 r-xp 00000000 08:06 3805680 /usr/lib/ruby/1.8/i686-linux/socket.so 00488000-00489000 r--p 00009000 08:06 3805680 /usr/lib/ruby/1.8/i686-linux/socket.so 00489000-0048a000 rw-p 0000a000 08:06 3805680 /usr/lib/ruby/1.8/i686-linux/socket.so 004f2000-00507000 r-xp 00000000 08:06 11403690 /lib/tls/i686/cmov/libpthread-2.11.1.so 00507000-00508000 r--p 00014000 08:06 11403690 /lib/tls/i686/cmov/libpthread-2.11.1.so 00508000-00509000 rw-p 00015000 08:06 11403690 /lib/tls/i686/cmov/libpthread-2.11.1.so 00509000-0050b000 rw-p 00000000 00:00 0 00524000-00525000 r-xp 00000000 00:00 0 [vdso] 00544000-00557000 r-xp 00000000 08:06 11403553 /lib/libz.so.1.2.3.3 00557000-00558000 r--p 00012000 08:06 11403553 /lib/libz.so.1.2.3.3 00558000-00559000 rw-p 00013000 08:06 11403553 /lib/libz.so.1.2.3.3 00639000-0063c000 r-xp 00000000 08:06 3805679 /usr/lib/ruby/1.8/i686-linux/thread.so 0063c000-0063d000 r--p 00002000 08:06 3805679 /usr/lib/ruby/1.8/i686-linux/thread.so 0063d000-0063e000 rw-p 00003000 08:06 3805679 /usr/lib/ruby/1.8/i686-linux/thread.so 00649000-0064d000 r-xp 00000000 08:06 11403714 /lib/tls/i686/cmov/libnss_dns-2.11.1.so 0064d000-0064e000 r--p 00004000 08:06 11403714 /lib/tls/i686/cmov/libnss_dns-2.11.1.so 0064e000-0064f000 rw-p 00005000 08:06 11403714 /lib/tls/i686/cmov/libnss_dns-2.11.1.so 00663000-006a3000 r-xp 00000000 08:06 4329500 /usr/lib/ruby/site_ruby/1.8/i686-linux/openssl.so 006a3000-006a4000 r--p 0003f000 08:06 4329500 /usr/lib/ruby/site_ruby/1.8/i686-linux/openssl.so 006a4000-006a5000 rw-p 00040000 08:06 4329500 /usr/lib/ruby/site_ruby/1.8/i686-linux/openssl.so 006a5000-006a6000 rw-p 00000000 00:00 0 0070d000-0070f000 r-xp 00000000 08:06 11403689 /lib/tls/i686/cmov/libdl-2.11.1.so 0070f000-00710000 r--p 00001000 08:06 11403689 /lib/tls/i686/cmov/libdl-2.11.1.so 00710000-00711000 rw-p 00002000 08:06 11403689 /lib/tls/i686/cmov/libdl-2.11.1.so 00711000-0084b000 r-xp 00000000 08:06 11403909 /lib/libcrypto.so.0.9.8 0084b000-00853000 r--p 00139000 08:06 11403909 /lib/libcrypto.so.0.9.8 00853000-00861000 rw-p 00141000 08:06 11403909 /lib/libcrypto.so.0.9.8 00861000-00864000 rw-p 00000000 00:00 0 00864000-00865000 ---p 00000000 00:00 0 00865000-00966000 rwxp 00000000 00:00 0 00977000-00979000 r-xp 00000000 08:06 11403476 /lib/libnss_mdns4_minimal.so.2 00979000-0097a000 r--p 00001000 08:06 11403476 /lib/libnss_mdns4_minimal.so.2 0097a000-0097b000 rw-p 00002000 08:06 11403476 /lib/libnss_mdns4_minimal.so.2 009fa000-00a04000 r-xp 00000000 08:06 11403691 /lib/tls/i686/cmov/libnss_files-2.11.1.so 00a04000-00a05000 r--p 00009000 08:06 11403691 /lib/tls/i686/cmov/libnss_files-2.11.1.so 00a05000-00a06000 rw-p 0000a000 08:06 11403691 /lib/tls/i686/cmov/libnss_files-2.11.1.so 00ac0000-00ac4000 r-xp 00000000 08:06 3805670 /usr/lib/ruby/1.8/i686-linux/stringio.so 00ac4000-00ac5000 r--p 00003000 08:06 3805670 /usr/lib/ruby/1.8/i686-linux/stringio.so 00ac5000-00ac6000 rw-p 00004000 08:06 3805670 /usr/lib/ruby/1.8/i686-linux/stringio.so 00af3000-00b0e000 r-xp 00000000 08:06 11403607 /lib/ld-2.11.1.so 00b0e000-00b0f000 r--p 0001a000 08:06 11403607 /lib/ld-2.11.1.so 00b0f000-00b10000 rw-p 0001b000 08:06 11403607 /lib/ld-2.11.1.so 00c35000-00c45000 r-xp 00000000 08:06 11403692 /lib/tls/i686/cmov/libresolv-2.11.1.so 00c45000-00c46000 r--p 00010000 08:06 11403692 /lib/tls/i686/cmov/libresolv-2.11.1.so 00c46000-00c47000 rw-p 00011000 08:06 11403692 /lib/tls/i686/cmov/libresolv-2.11.1.so 00c47000-00c49000 rw-p 00000000 00:00 0 00d51000-00d59000 r-xp 00000000 08:06 4329502 /usr/lib/ruby/site_ruby/1.8/i686-linux/zlib.so 00d59000-00d5a000 r--p 00007000 08:06 4329502 /usr/lib/ruby/site_ruby/1.8/i686-linux/zlib.so 00d5a000-00d5b000 rw-p 00008000 08:06 4329502 /usr/lib/ruby/site_ruby/1.8/i686-linux/zlib.so 00d60000-00d61000 r-xp 00000000 08:06 3805664 /usr/lib/ruby/1.8/i686-linux/rational.so 00d61000-00d62000 r--p 00000000 08:06 3805664 /usr/lib/ruby/1.8/i686-linux/rational.so 00d62000-00d63000 rw-p 00001000 08:06 3805664 /usr/lib/ruby/1.8/i686-linux/rational.so 00de6000-00de9000 r-xp 00000000 08:06 3805691 /usr/lib/ruby/1.8/i686-linux/digest.so 00de9000-00dea000 r--p 00002000 08:06 3805691 /usr/lib/ruby/1.8/i686-linux/digest.so 00dea000-00deb000 rw-p 00003000 08:06 3805691 /usr/lib/ruby/1.8/i686-linux/digest.so 00e63000-00e6a000 r-xp 00000000 08:06 11403700 /lib/tls/i686/cmov/librt-2.11.1.so 00e6a000-00e6b000 r--p 00006000 08:06 11403700 /lib/tls/i686/cmov/librt-2.11.1.so 00e6b000-00e6c000 rw-p 00007000 08:06 11403700 /lib/tls/i686/cmov/librt-2.11.1.so 00f70000-00fb4000 r-xp 00000000 08:06 11403907 /lib/libssl.so.0.9.8Aborted

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

1