Error _armv7_tick openssl

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Error _armv7_tick openssl

Jay D Bhatt

Hi ,

 

I was working on a armv7l architecture platform and was trying to run webruntime related library, but it was crashing _armv7_tick(). So, I did GDB on the wrt binary and below are the logs:

 

root:/usr/bin> gdb wrt_launchpad_daemon

GNU gdb (GDB) 7.5.1

Copyright (C) 2012 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "armv7l-tizen-linux-gnueabi".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols found)...done.

(gdb) run

Starting program: /usr/bin/wrt_launchpad_daemon

warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

To enable execution of this file add

        add-auto-load-safe-path /usr/lib/libthread_db.so.1

line to your configuration file "/root/.gdbinit".

To completely disable this security protection add

        set auto-load safe-path /

line to your configuration file "/root/.gdbinit".

For more information about this security protection see the

"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:

        info "(gdb)Auto-loading safe path"

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

 

Program received signal SIGILL, Illegal instruction.

0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0

(gdb) bt

#0  0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0

#1  0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0

#2  0x2aab5e0e in call_init () from /lib/ld-linux.so.3

#3  0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3

#4  0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3

#5  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3

#6  0x2aab8642 in _dl_open () from /lib/ld-linux.so.3

#7  0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2

#8  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3

#9  0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2

#10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2

#11 0x0000a744 in main ()

(gdb) disas _armv7_tick

Dump of assembler code for function _armv7_tick:

=> 0x2e2b76e8 <+0>:     mrc     15, 0, r0, cr9, cr13, {0}

   0x2e2b76ec <+4>:     bx      lr

End of assembler dump.

 

 

 

It seems that either the architecture platform is not able to identify the instructions or some other reason, due to which it fails.

Has anyone faced similar problem? Could anybody suggest some solution or patch which can solve this issue?

 

Thanks,

Jay


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or [hidden email]. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reply | Threaded
Open this post in threaded view
|

Re: Error _armv7_tick openssl

Fedor Indutny
Hello!

I'm not a OpenSSL core developer, but anyway here are some thoughts from me.

SIGILL is totally a normal condition, as it is caught by:


This is a part of detecting features, so if you wish to get more details - please enter `continue` after catching SIGILL in gdb.

Thanks,
Fedor.

On Fri, Oct 10, 2014 at 7:52 AM, Jay D Bhatt <[hidden email]> wrote:

Hi ,

 

I was working on a armv7l architecture platform and was trying to run webruntime related library, but it was crashing _armv7_tick(). So, I did GDB on the wrt binary and below are the logs:

 

root:/usr/bin> gdb wrt_launchpad_daemon

GNU gdb (GDB) 7.5.1

Copyright (C) 2012 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "armv7l-tizen-linux-gnueabi".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols found)...done.

(gdb) run

Starting program: /usr/bin/wrt_launchpad_daemon

warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

To enable execution of this file add

        add-auto-load-safe-path /usr/lib/libthread_db.so.1

line to your configuration file "/root/.gdbinit".

To completely disable this security protection add

        set auto-load safe-path /

line to your configuration file "/root/.gdbinit".

For more information about this security protection see the

"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:

        info "(gdb)Auto-loading safe path"

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

 

Program received signal SIGILL, Illegal instruction.

0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0

(gdb) bt

#0  0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0

#1  0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0

#2  0x2aab5e0e in call_init () from /lib/ld-linux.so.3

#3  0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3

#4  0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3

#5  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3

#6  0x2aab8642 in _dl_open () from /lib/ld-linux.so.3

#7  0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2

#8  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3

#9  0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2

#10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2

#11 0x0000a744 in main ()

(gdb) disas _armv7_tick

Dump of assembler code for function _armv7_tick:

=> 0x2e2b76e8 <+0>:     mrc     15, 0, r0, cr9, cr13, {0}

   0x2e2b76ec <+4>:     bx      lr

End of assembler dump.

 

 

 

It seems that either the architecture platform is not able to identify the instructions or some other reason, due to which it fails.

Has anyone faced similar problem? Could anybody suggest some solution or patch which can solve this issue?

 

Thanks,

Jay


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or [hidden email]. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Reply | Threaded
Open this post in threaded view
|

RE: Error _armv7_tick openssl

Jay D Bhatt

Hi Fedor,

 

If I press ‘continue’, then also it give segmentation fault. It is not working normally, it exits with seg fault: saying illegal instruction.Could you suggest any other solution? The assembly instruction which I mentioned in my log was identified as illegal instruction.

 

Thanks,

Jay

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Fedor Indutny
Sent: 10 October 2014 15:29
To: [hidden email]
Subject: Re: Error _armv7_tick openssl

 

Hello!

 

I'm not a OpenSSL core developer, but anyway here are some thoughts from me.

 

SIGILL is totally a normal condition, as it is caught by:

 

 

This is a part of detecting features, so if you wish to get more details - please enter `continue` after catching SIGILL in gdb.

 

Thanks,

Fedor.

 

On Fri, Oct 10, 2014 at 7:52 AM, Jay D Bhatt <[hidden email]> wrote:

Hi ,

 

I was working on a armv7l architecture platform and was trying to run webruntime related library, but it was crashing _armv7_tick(). So, I did GDB on the wrt binary and below are the logs:

 

root:/usr/bin> gdb wrt_launchpad_daemon

GNU gdb (GDB) 7.5.1

Copyright (C) 2012 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "armv7l-tizen-linux-gnueabi".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols found)...done.

(gdb) run

Starting program: /usr/bin/wrt_launchpad_daemon

warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

To enable execution of this file add

        add-auto-load-safe-path /usr/lib/libthread_db.so.1

line to your configuration file "/root/.gdbinit".

To completely disable this security protection add

        set auto-load safe-path /

line to your configuration file "/root/.gdbinit".

For more information about this security protection see the

"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:

        info "(gdb)Auto-loading safe path"

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

 

Program received signal SIGILL, Illegal instruction.

0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0

(gdb) bt

#0  0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0

#1  0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0

#2  0x2aab5e0e in call_init () from /lib/ld-linux.so.3

#3  0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3

#4  0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3

#5  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3

#6  0x2aab8642 in _dl_open () from /lib/ld-linux.so.3

#7  0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2

#8  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3

#9  0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2

#10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2

#11 0x0000a744 in main ()

(gdb) disas _armv7_tick

Dump of assembler code for function _armv7_tick:

=> 0x2e2b76e8 <+0>:     mrc     15, 0, r0, cr9, cr13, {0}

   0x2e2b76ec <+4>:     bx      lr

End of assembler dump.

 

 

 

It seems that either the architecture platform is not able to identify the instructions or some other reason, due to which it fails.

Has anyone faced similar problem? Could anybody suggest some solution or patch which can solve this issue?

 

Thanks,

Jay


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or [hidden email]. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or [hidden email]. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reply | Threaded
Open this post in threaded view
|

Re: Error _armv7_tick openssl

Fedor Indutny
Jay,

I seen the reports of this error on node.js issue tracker, but don't have any other information about it yet, since I'm unable to reproduce it on my raspberry pi.

What I tried to say, is that Illegal instruction and the SIGILL is the way OpenSSL tries to figure out the supported features. It should not be the source of the bug, just a part of initialisation process. The bug is most likely happening right after this, when you see the actual crash.

Sorry for not much details,
Fedor.

On Fri, Oct 10, 2014 at 3:07 PM, Jay D Bhatt <[hidden email]> wrote:

Hi Fedor,

 

If I press ‘continue’, then also it give segmentation fault. It is not working normally, it exits with seg fault: saying illegal instruction.Could you suggest any other solution? The assembly instruction which I mentioned in my log was identified as illegal instruction.

 

Thanks,

Jay

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Fedor Indutny
Sent: 10 October 2014 15:29
To: [hidden email]
Subject: Re: Error _armv7_tick openssl

 

Hello!

 

I'm not a OpenSSL core developer, but anyway here are some thoughts from me.

 

SIGILL is totally a normal condition, as it is caught by:

 

 

This is a part of detecting features, so if you wish to get more details - please enter `continue` after catching SIGILL in gdb.

 

Thanks,

Fedor.

 

On Fri, Oct 10, 2014 at 7:52 AM, Jay D Bhatt <[hidden email]> wrote:

Hi ,

 

I was working on a armv7l architecture platform and was trying to run webruntime related library, but it was crashing _armv7_tick(). So, I did GDB on the wrt binary and below are the logs:

 

root:/usr/bin> gdb wrt_launchpad_daemon

GNU gdb (GDB) 7.5.1

Copyright (C) 2012 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "armv7l-tizen-linux-gnueabi".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols found)...done.

(gdb) run

Starting program: /usr/bin/wrt_launchpad_daemon

warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

To enable execution of this file add

        add-auto-load-safe-path /usr/lib/libthread_db.so.1

line to your configuration file "/root/.gdbinit".

To completely disable this security protection add

        set auto-load safe-path /

line to your configuration file "/root/.gdbinit".

For more information about this security protection see the

"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:

        info "(gdb)Auto-loading safe path"

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

 

Program received signal SIGILL, Illegal instruction.

0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0

(gdb) bt

#0  0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0

#1  0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0

#2  0x2aab5e0e in call_init () from /lib/ld-linux.so.3

#3  0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3

#4  0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3

#5  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3

#6  0x2aab8642 in _dl_open () from /lib/ld-linux.so.3

#7  0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2

#8  0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3

#9  0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2

#10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2

#11 0x0000a744 in main ()

(gdb) disas _armv7_tick

Dump of assembler code for function _armv7_tick:

=> 0x2e2b76e8 <+0>:     mrc     15, 0, r0, cr9, cr13, {0}

   0x2e2b76ec <+4>:     bx      lr

End of assembler dump.

 

 

 

It seems that either the architecture platform is not able to identify the instructions or some other reason, due to which it fails.

Has anyone faced similar problem? Could anybody suggest some solution or patch which can solve this issue?

 

Thanks,

Jay


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or [hidden email]. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or [hidden email]. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Reply | Threaded
Open this post in threaded view
|

Re: Error _armv7_tick openssl

Andy Polyakov-2
In reply to this post by Jay D Bhatt
> If I press ‘continue’, then also it give segmentation fault. It is not
> working normally, it exits with seg fault: saying illegal
> instruction.

??? Segmentation fault != illegal instruction. What does "exits with seg
fault saying illegal instruction" mean? Where is the segmentation fault?

> Could you suggest any other solution? The assembly
> instruction which I mentioned in my log was identified as illegal
> instruction.

https://www.openssl.org/support/faq.html#PROG17. There are two options
listed.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Error _armv7_tick openssl

Misaki Miyashita
On 10/10/14 10:15, Andy Polyakov wrote:

>> If I press ‘continue’, then also it give segmentation fault. It is not
>> working normally, it exits with seg fault: saying illegal
>> instruction.
> ??? Segmentation fault != illegal instruction. What does "exits with seg
> fault saying illegal instruction" mean? Where is the segmentation fault?
>
>> Could you suggest any other solution? The assembly
>> instruction which I mentioned in my log was identified as illegal
>> instruction.
> https://www.openssl.org/support/faq.html#PROG17. There are two options
> listed.

As Fedor mentioned, it is expected to see some SIGILL at the beginning
of the OpenSSL application as that's how OpenSSL checks the hardware
capabilities.  If you are running your application with a debugger, a
debugger may catch SIGILL signals multiple times, so you may have to hit
"continue" multiple times to resume.

As explained in the FAQ page listed by Andy, you can workaround it by:

/@ == gdb ==/
/@ adding 'handle SIGILL nostop' to your .gdbinit./

/@ == mdb ==/
/@ running '4:i' at the mdb prompt./


Once you set the workaround, the debugger ignores SIGILL so that you
don't have to hit "continue".

-- misaki

Oracle Solaris Security
Senior Software Engineer
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Error _armv7_tick openssl

Peter Waltenberg
In reply to this post by Andy Polyakov-2
ARM is one of those awkward processors, the event counter isn't always directly readable from userspace, if it's not directly readable you get an illegal instruction trap. A syscall to access the event counters is only present in recent kernels. And even more fun, the event counter data is only readable from the thread that enabled the event counters.

The bad news is that without  the event counters, there are no good entropy sources - and dying with a segv is likely the best possible outcome.

Peter

This  code works (for a certain value of 'work') on recent kernels.

#elif defined(__ARMEL__) || defined(__ARMEB__)
/* ARM */
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/ioctl.h>
#include <linux/perf_event.h>
#include <asm/unistd.h>

static inline long long
armtick(void)
{
  int fddev = -1;
 long long result = 0;
 static struct perf_event_attr attr;
 attr.type = PERF_TYPE_HARDWARE;
 attr.config = PERF_COUNT_HW_CPU_CYCLES;
 fddev = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0);
 if (read(fddev, &result, sizeof(result)) < sizeof(result)) return 0;
 close(fddev);
 return result;
}

Not exactly efficient.

Peter

-----[hidden email] wrote: -----
To: [hidden email]
From: Andy Polyakov
Sent by: [hidden email]
Date: 10/11/2014 01:17AM
Subject: Re: Error _armv7_tick openssl

> If I press ‘continue’, then also it give segmentation fault. It is not
> working normally, it exits with seg fault: saying illegal
> instruction.

??? Segmentation fault != illegal instruction. What does "exits with seg
fault saying illegal instruction" mean? Where is the segmentation fault?

> Could you suggest any other solution? The assembly
> instruction which I mentioned in my log was identified as illegal
> instruction.

https://www.openssl.org/support/faq.html#PROG17. There are two options
listed.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [hidden email] Automated List Manager [hidden email]