Fix works for me as well - thanks for following up, appreciate this was an obscure one in an officially unsupported API<br><br>On Friday, 17 July 2015, Vladimir Kozlov <<a href="mailto:vladimir.kozlov@oracle.com">vladimir.kozlov@oracle.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is in released few days ago JDK 8u51:<br>
<br>
<a href="http://www.oracle.com/technetwork/java/javase/8u51-relnotes-2587590.html" target="_blank">http://www.oracle.com/technetwork/java/javase/8u51-relnotes-2587590.html</a><br>
<br>
Regards,<br>
Vladimir<br>
<br>
On 7/17/15 12:49 PM, Serkan Özal wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi John,<br>
<br>
Yes, I have applied your fix and it works.<br>
Thanks!<br>
<br>
Since which JDK version this patch will be there?<br>
<br>
Regards.<br>
<br>
On Fri, Jul 17, 2015 at 10:31 PM, John Rose <<a>john.r.rose@oracle.com</a><br>
<mailto:<a>john.r.rose@oracle.com</a>>> wrote:<br>
<br>
    Thanks Serkan and Martijn for reporting and analyzing this.<br>
<br>
    We had a very similar bug reported internally, and we just<br>
    integrated a fix:<br>
    <a href="http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/3816de51b5e7" target="_blank">http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/3816de51b5e7</a><br>
<br>
    Would you mind checking if it fixes your problem also?<br>
<br>
    Best wishes,<br>
    — John<br>
<br>
    On Jul 12, 2015, at 5:07 AM, Serkan Özal <<a>serkan@hazelcast.com</a><br>
    <mailto:<a>serkan@hazelcast.com</a>>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    Hi Martjin,<br>
<br>
    Thanks for your interest and comment for making this thread a<br>
    little bit more hot.<br>
<br>
<br>
    From my previous message<br>
    (<a href="http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-June/018221.html" target="_blank">http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-June/018221.html</a>):<br>
<br>
        I added some additional logs to *"vm/c1/c1_Canonicalizer.cpp"*:<br>
<br>
<br>
        void Canonicalizer::do_UnsafeGetRaw(UnsafeGetRaw* x) {<br>
<br>
        if (OptimizeUnsafes) do_UnsafeRawOp(x);<br>
<br>
        tty->print_cr("Canonicalizer: do_UnsafeGetRaw id %d: base = id<br>
        %d, index = id %d, log2_scale = %d",<br>
<br>
        x->id(), x->base()->id(), x->index()->id(), x->log2_scale());<br>
<br>
        }<br>
<br>
<br>
        void Canonicalizer::do_UnsafePutRaw(UnsafePutRaw* x) {<br>
<br>
        if (OptimizeUnsafes) do_UnsafeRawOp(x);<br>
<br>
        tty->print_cr("Canonicalizer: do_UnsafePutRaw id %d: base = id<br>
        %d, index = id %d, log2_scale = %d",<br>
<br>
        x->id(), x->base()->id(), x->index()->id(), x->log2_scale());<br>
<br>
        }<br>
<br>
<br>
<br>
        So I run the test by calculating address as:<br>
<br>
        - *"int * long"* (int is index and long is 8l)<br>
<br>
        - *"long * long"* (the first long is index and the second long<br>
        is 8l)<br>
<br>
        - *"int * int"* (the first int is index and the second int is 8)<br>
<br>
        Here are the logs:<br>
<br>
<br>
        *int * long:*<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 18: base = id 16, index = id<br>
        17, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 20: base = id 16, index = id<br>
        19, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 22: base = id 16, index = id<br>
        21, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 24: base = id 16, index = id<br>
        23, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafePutRaw id 33: base = id 13, index = id<br>
        27, log2_scale = 3<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 36: base = id 13, index = id<br>
        27, log2_scale = 3<br>
<br>
        *long * long:*<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 18: base = id 16, index = id<br>
        17, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 20: base = id 16, index = id<br>
        19, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 22: base = id 16, index = id<br>
        21, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 24: base = id 16, index = id<br>
        23, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafePutRaw id 35: base = id 13, index = id<br>
        14, log2_scale = 3<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 37: base = id 13, index = id<br>
        14, log2_scale = 3<br>
<br>
        *int * int:*<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 18: base = id 16, index = id<br>
        17, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 20: base = id 16, index = id<br>
        19, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 22: base = id 16, index = id<br>
        21, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 24: base = id 16, index = id<br>
        23, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafePutRaw id 33: base = id 13, index = id<br>
        29, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 36: base = id 13, index = id<br>
        29, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafePutRaw id 19: base = id 8, index = id<br>
        15, log2_scale = 0<br>
<br>
        Canonicalizer: do_UnsafeGetRaw id 22: base = id 8, index = id<br>
        15, log2_scale = 0<br>
<br>
        As you can see, at the problematic runs (*"int * long"* and<br>
        *"long * long"*) there are two scaling.<br>
<br>
        One for *"Unsafe.put"* and the other one is for*"Unsafe.get"*<br>
        and these instructions points to<br>
<br>
        same *"base"* and *"index"* instructions. This means that<br>
        address is scaled one more time because there should be only<br>
        one scale.<br>
<br>
<br>
<br>
    With this fix (or attempt since I am not %100 sure if it is<br>
    perfect/optimum way or not), I prevent multiple scaling on the<br>
    same index instruction.<br>
<br>
    Also one of my previous messages<br>
    (<a href="http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-July/018383.html" target="_blank">http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-July/018383.html</a>)<br>
    shows that there are multiple scaling on the index so when it<br>
    scaled multiple, anymore it shows somewhere or anywhere in the memory.<br>
<br>
    On Sun, Jul 12, 2015 at 2:54 PM, Martijn Verburg<br>
    <<a>martijnverburg@gmail.com</a> <mailto:<a>martijnverburg@gmail.com</a>>> wrote:<br>
<br>
        Non reviewer here, but I'd add to the comment *why* you don't<br>
        want to scale again.<br>
<br>
        Cheers,<br>
        Martijn<br>
<br>
        On 12 July 2015 at 11:29, Serkan Özal <<a>serkan@hazelcast.com</a><br>
        <mailto:<a>serkan@hazelcast.com</a>>> wrote:<br>
<br>
            Hi all,<br>
<br>
            I have created a webrev for review including the patch and<br>
            shared for public access from here:<br>
            <a href="https://s3.amazonaws.com/jdk-8087134/webrev.00/index.html" target="_blank">https://s3.amazonaws.com/jdk-8087134/webrev.00/index.html</a><br>
<br>
            Regards.<br>
<br>
            On Sat, Jul 4, 2015 at 9:06 PM, Serkan Özal<br>
            <<a>serkan@hazelcast.com</a> <mailto:<a>serkan@hazelcast.com</a>>> wrote:<br>
<br>
                Hi,<br>
<br>
                I have added some logs to show that problem is caused<br>
                by double scaling of offset (index)<br>
<br>
                Here is my updated (log messages added) reproducer code:<br>
<br>
<br>
                int count = 100000;<br>
                long size = count * 8L;<br>
                long baseAddress = unsafe.allocateMemory(size);<br>
                System.out.println("Start address: " +<br>
                Long.toHexString(baseAddress) +<br>
                                   ", End address: " +<br>
                Long.toHexString(baseAddress + size));<br>
<br>
                for (int i = 0; i < count; i++) {<br>
                    long address = baseAddress + (i * 8L);<br>
                    System.out.println(<br>
                        "Normal: " + Long.toHexString(address) + ", " +<br>
                        "If double scaled: " +<br>
                Long.toHexString(baseAddress + (i * 8L * 8L)));<br>
                    long expected = i;<br>
                    unsafe.putLong(address, expected);<br>
                    unsafe.getLong(address);<br>
                }<br>
<br>
<br>
                After sometime it crashes as<br>
<br>
<br>
                ...<br>
                Current thread (0x0000000002068800):  JavaThread<br>
                "main" [_thread_in_Java, id=10412,<br>
                stack(0x00000000023f0000,0x00000000024f0000)]<br>
<br>
                siginfo: ExceptionCode=0xc0000005, reading address<br>
                0x0000000059061020<br>
                ...<br>
                ...<br>
<br>
<br>
                And here is output of the execution until crash:<br>
<br>
                Start address: 58bbcfa0, End address: 58c804a0<br>
                Normal: 58bbcfa0, If double scaled: 58bbcfa0<br>
                Normal: 58bbcfa8, If double scaled: 58bbcfe0<br>
                Normal: 58bbcfb0, If double scaled: 58bbd020<br>
                ...<br>
                ...<br>
                Normal: 58c517b0, If double scaled: 59061020<br>
<br>
<br>
                As seen from the logs and crash dump, double scaled<br>
                version of target address (*If double scaled:<br>
                59061020*) is the same with the problematic address<br>
                (*siginfo: ExceptionCode=0xc0000005, reading address<br>
                0x0000000059061020*) that causes to crash while<br>
                accessing it.<br>
<br>
                So I think, it is obvious that the crash is caused by<br>
                wrong optimization of index value since index is<br>
                scaled two times (for *Unsafe::put* and *Unsafe::get*)<br>
                instead of only one time. Then double scaled index<br>
                points to invalid memory address.<br>
<br>
                Regards.<br>
<br>
                On Sun, Jun 14, 2015 at 2:39 PM, Serkan Özal<br>
                <<a>serkan@hazelcast.com</a> <mailto:<a>serkan@hazelcast.com</a>>><br>
                wrote:<br>
<br>
                    Hi all, I had dived into the issue with<br>
                    JDK-HotSpot commits and the issue arised after<br>
                    this commit:<br>
                    <a href="http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/a60a1309a03a" target="_blank">http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/a60a1309a03a</a><br>
                    Then I added some additional logs to<br>
                    *"vm/c1/c1_Canonicalizer.cpp"*: void<br>
                    Canonicalizer::do_UnsafeGetRaw(UnsafeGetRaw* x) {<br>
                    if (OptimizeUnsafes) do_UnsafeRawOp(x);<br>
                    tty->print_cr("Canonicalizer: do_UnsafeGetRaw id<br>
                    %d: base = id %d, index = id %d, log2_scale = %d",<br>
                    x->id(), x->base()->id(), x->index()->id(),<br>
                    x->log2_scale()); } void<br>
                    Canonicalizer::do_UnsafePutRaw(UnsafePutRaw* x) {<br>
                    if (OptimizeUnsafes) do_UnsafeRawOp(x);<br>
                    tty->print_cr("Canonicalizer: do_UnsafePutRaw id<br>
                    %d: base = id %d, index = id %d, log2_scale = %d",<br>
                    x->id(), x->base()->id(), x->index()->id(),<br>
                    x->log2_scale()); }<br>
<br>
                    So I run the test by calculating address as -<br>
                    *"int * long"* (int is index and long is 8l) -<br>
                    *"long * long"* (the first long is index and the<br>
                    second long is 8l) - *"int * int"* (the first int<br>
                    is index and the second int is 8) Here are the<br>
                    logs: *int * long:* Canonicalizer: do_UnsafeGetRaw<br>
                    id 18: base = id 16, index = id 17, log2_scale = 0<br>
                    Canonicalizer: do_UnsafeGetRaw id 20: base = id<br>
                    16, index = id 19, log2_scale = 0 Canonicalizer:<br>
                    do_UnsafeGetRaw id 22: base = id 16, index = id<br>
                    21, log2_scale = 0 Canonicalizer: do_UnsafeGetRaw<br>
                    id 24: base = id 16, index = id 23, log2_scale = 0<br>
                    Canonicalizer: do_UnsafePutRaw id 33: base = id<br>
                    13, index = id 27, log2_scale = 3 Canonicalizer:<br>
                    do_UnsafeGetRaw id 36: base = id 13, index = id<br>
                    27, log2_scale = 3*long * long:* Canonicalizer:<br>
                    do_UnsafeGetRaw id 18: base = id 16, index = id<br>
                    17, log2_scale = 0 Canonicalizer: do_UnsafeGetRaw<br>
                    id 20: base = id 16, index = id 19, log2_scale = 0<br>
                    Canonicalizer: do_UnsafeGetRaw id 22: base = id<br>
                    16, index = id 21, log2_scale = 0 Canonicalizer:<br>
                    do_UnsafeGetRaw id 24: base = id 16, index = id<br>
                    23, log2_scale = 0 Canonicalizer: do_UnsafePutRaw<br>
                    id 35: base = id 13, index = id 14, log2_scale = 3<br>
                    Canonicalizer: do_UnsafeGetRaw id 37: base = id<br>
                    13, index = id 14, log2_scale = 3*int * int:*<br>
                    Canonicalizer: do_UnsafeGetRaw id 18: base = id<br>
                    16, index = id 17, log2_scale = 0 Canonicalizer:<br>
                    do_UnsafeGetRaw id 20: base = id 16, index = id<br>
                    19, log2_scale = 0 Canonicalizer: do_UnsafeGetRaw<br>
                    id 22: base = id 16, index = id 21, log2_scale = 0<br>
                    Canonicalizer: do_UnsafeGetRaw id 24: base = id<br>
                    16, index = id 23, log2_scale = 0 Canonicalizer:<br>
                    do_UnsafePutRaw id 33: base = id 13, index = id<br>
                    29, log2_scale = 0 Canonicalizer: do_UnsafeGetRaw<br>
                    id 36: base = id 13, index = id 29, log2_scale = 0<br>
                    Canonicalizer: do_UnsafePutRaw id 19: base = id 8,<br>
                    index = id 15, log2_scale = 0 Canonicalizer:<br>
                    do_UnsafeGetRaw id 22: base = id 8, index = id 15,<br>
                    log2_scale = 0As you can see, at the problematic<br>
                    runs (*"int * long"* and *"long * long"*) there<br>
                    are two scaling. One for *"Unsafe.put"* and the<br>
                    other one is for*"Unsafe.get"* and these<br>
                    instructions points to same *"base"* and *"index"*<br>
                    instructions. This means that address is scaled<br>
                    one more time because there should be only one scale.<br>
<br>
                    When I debugged the non-problematic run (*"int *<br>
                    int"*), I saw that *"instr->as_ArithmeticOp();"*<br>
                    is always returns *"null" *then<br>
                    *"match_index_and_scale"* method returns*"false"*<br>
                    always. So there is no scaling. static bool<br>
                    match_index_and_scale(Instruction* instr,<br>
                    Instruction** index, int* log2_scale) { ...<br>
                    ArithmeticOp* arith = instr->as_ArithmeticOp(); if<br>
                    (arith != NULL) { ... } return false; }<br>
<br>
                    Then I have added my fix attempt to prevent<br>
                    multiple scaling for Unsafe instructions points to<br>
                    same index instruction like this: void<br>
                    Canonicalizer::do_UnsafeRawOp(UnsafeRawOp* x) {<br>
                    Instruction* base = NULL; Instruction* index =<br>
                    NULL; int log2_scale; if (match(x, &base, &index,<br>
                    &log2_scale)) { x->set_base(base);<br>
                    x->set_index(index); // The fix attempt here //<br>
                    ///////////////////////////// if (index != NULL) {<br>
                    if (index->is_pinned()) { log2_scale = 0; } else {<br>
                    if (log2_scale != 0) { index->pin(); } } } //<br>
                    /////////////////////////////<br>
                    x->set_log2_scale(log2_scale); if<br>
                    (PrintUnsafeOptimization) {<br>
                    tty->print_cr("Canonicalizer: UnsafeRawOp id %d:<br>
                    base = id %d, index = id %d, log2_scale = %d",<br>
                    x->id(), x->base()->id(), x->index()->id(),<br>
                    x->log2_scale()); } } } In this fix attempt, if<br>
                    there is a scaling for the Unsafe instruction, I<br>
                    pin index instruction of that instruction and at<br>
                    next calls, if the index instruction is pinned, I<br>
                    assummed that there is already scaling so no need<br>
                    to another scaling. After this fix, I rerun the<br>
                    problematic test (*"int * long"*) and it works<br>
                    with these logs: *int * long (after fix):*<br>
                    Canonicalizer: do_UnsafeGetRaw id 18: base = id<br>
                    16, index = id 17, log2_scale = 0 Canonicalizer:<br>
                    do_UnsafeGetRaw id 20: base = id 16, index = id<br>
                    19, log2_scale = 0 Canonicalizer: do_UnsafeGetRaw<br>
                    id 22: base = id 16, index = id 21, log2_scale = 0<br>
                    Canonicalizer: do_UnsafeGetRaw id 24: base = id<br>
                    16, index = id 23, log2_scale = 0 Canonicalizer:<br>
                    do_UnsafePutRaw id 35: base = id 13, index = id<br>
                    14, log2_scale = 3 Canonicalizer: do_UnsafeGetRaw<br>
                    id 37: base = id 13, index = id 14, log2_scale = 0<br>
                    Canonicalizer: do_UnsafePutRaw id 21: base = id 8,<br>
                    index = id 11, log2_scale = 3 Canonicalizer:<br>
                    do_UnsafeGetRaw id 23: base = id 8, index = id 11,<br>
                    log2_scale = 0I am not sure my fix attempt is a<br>
                    really fix or maybe there are better fixes.<br>
                    Regards. -- Serkan ÖZAL<br>
<br>
                        Btw, (thanks to one my colleagues), when<br>
                        address calculation in the loop is<br>
                        converted to long address = baseAddress + (i *<br>
                        8) test passes. Only difference is next long<br>
                        pointer is calculated using<br>
                        integer 8 instead of long 8. ```<br>
                        for (int i = 0; i < count; i++) {<br>
                        long address = baseAddress + (i * 8); // <---<br>
                        here, integer 8 instead<br>
                        of long 8 long expected = i;<br>
                        unsafe.putLong(address, expected); long actual<br>
                        = unsafe.getLong(address); if (expected !=<br>
                        actual) {<br>
                        throw new AssertionError("Expected: " +<br>
                        expected + ", Actual: " +<br>
                        actual);<br>
                        }<br>
                        }<br>
                        ``` On Tue, Jun 9, 2015 at 1:07 PM Mehmet<br>
                        Dogan <mehmet at <a href="http://hazelcast.com" target="_blank">hazelcast.com</a><br>
                        <<a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-compiler-dev" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-compiler-dev</a>>><br>
                        wrote: >/Hi all, /><br>
                        >/While I was testing my app using java 8, I<br>
                        encountered the previously />/reported<br>
                        sun.misc.Unsafe issue. /><br>
                        >/<a href="https://bugs.openjdk.java.net/browse/JDK-8076445" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8076445</a><br>
                        /><br>
                        >/<a href="http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017685.html" target="_blank">http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017685.html</a><br>
                        /><br>
                        >/Issue status says it's resolved with<br>
                        resolution "Cannot Reproduce". But<br>
                        />/unfortunately it's still reproducible using<br>
                        "1.8.0_60-ea-b18" and />/"1.9.0-ea-b67". /><br>
                        >/Test is very simple: /><br>
                        >/``` />/public static void main(String[]<br>
                        args) throws Exception { />/Unsafe unsafe =<br>
                        findUnsafe(); />/// 10000 pass />/// 100000<br>
                        jvm crash />/// 1000000 fail />/int count =<br>
                        100000; />/long size = count * 8L; />/long<br>
                        baseAddress = unsafe.allocateMemory(size); /><br>
                        >/try { />/for (int i = 0; i < count; i++) {<br>
                        />/long address = baseAddress + (i * 8L); /><br>
                        >/long expected = i;<br>
                        />/unsafe.putLong(address, expected); /><br>
                        >/long actual = unsafe.getLong(address); /><br>
                        >/if (expected != actual) { />/throw new<br>
                        AssertionError("Expected: " + expected + ",<br>
                        />/Actual: " + actual); />/} />/} />/} finally<br>
                        { />/unsafe.freeMemory(baseAddress); />/} />/}<br>
                        />/``` />/It's not failing up to version<br>
                        1.8.0.31, by starting 1.8.0.40 test is<br>
                        />/failing constantly. /><br>
                        >/- With iteration count 10000, test is<br>
                        passing. />/- With iteration count 100000, jvm<br>
                        is crashing with SIGSEGV. />/- With iteration<br>
                        count 1000000, test is failing with<br>
                        AssertionError. /><br>
                        >/When one of compilation (-Xint) or inlining<br>
                        (-XX:-Inline) or />/on-stack-replacement<br>
                        (-XX:-UseOnStackReplacement) is disabled, test<br>
                        is not />/failing at all. /><br>
                        >/I tested on platforms: />/-<br>
                        Centos-7/openjdk-1.8.0.45 />/-<br>
                        OSX/oraclejdk-1.8.0.40 />/-<br>
                        OSX/oraclejdk-1.8.0.45 />/-<br>
                        OSX/oraclejdk-1.8.0_60-ea-b18 />/-<br>
                        OSX/oraclejdk-1.9.0-ea-b67 /><br>
                        >/Previous issue comment (<br>
                        />/<a href="https://bugs.openjdk.java.net/browse/JDK-8076445?focusedCommentId=13633043#comment-13633043" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8076445?focusedCommentId=13633043#comment-13633043</a>)<br>
                        />/says "Cannot reproduce based on the latest<br>
                        version". I hope that latest />/version is not<br>
                        mentioning to '1.8.0_60-ea-b18' or<br>
                        '1.9.0-ea-b67'. Because />/both are failing. /><br>
                        >/I'm looking forward to hearing from you. /><br>
                        >/Thanks, />/-Mehmet Dogan- />/-- /><br>
                        >/@mmdogan /><br>
<br>
<br>
                    --<br>
                    Serkan ÖZAL<br>
                    Remotest Software Engineer<br>
                    GSM: +90 542 680 39 18<br>
                    <tel:%2B90%20542%20680%2039%2018><br>
                    Twitter: @serkan_ozal<br>
<br>
<br>
<br>
<br>
                --<br>
                Serkan ÖZAL<br>
                Remotest Software Engineer<br>
                GSM: +90 542 680 39 18 <tel:%2B90%20542%20680%2039%2018><br>
                Twitter: @serkan_ozal<br>
<br>
<br>
<br>
<br>
            --<br>
            Serkan ÖZAL<br>
            Remotest Software Engineer<br>
            GSM: +90 542 680 39 18 <tel:%2B90%20542%20680%2039%2018><br>
            Twitter: @serkan_ozal<br>
<br>
<br>
<br>
<br>
<br>
    --<br>
    Serkan ÖZAL<br>
    Remotest Software Engineer<br>
    GSM: +90 542 680 39 18 <tel:%2B90%20542%20680%2039%2018><br>
    Twitter: @serkan_ozal<br>
</blockquote>
<br>
<br>
<br>
<br>
--<br>
Serkan ÖZAL<br>
Remotest Software Engineer<br>
GSM: +90 542 680 39 18<br>
Twitter: @serkan_ozal<br>
</blockquote>
</blockquote><br><br>-- <br>Cheers, Martijn (Sent from Gmail Mobile)<br>