Project Home
Project Home		 Source Code
Source Code		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Core Development Tools/Discussion/General/memcpy and memset crashes with SIGSEGV/List of Posts
Forum Topic - memcpy and memset crashes with SIGSEGV: (19 Items)
   
Update
Girisha SG
10/06/2010 5:48 AM
post69699
memcpy and memset crashes with SIGSEGV   
I am compiling the code using RVCT and linking it using ld (EABI technique is used for inter operability). When I use 
the standard memcpy & memset functions in the code the executable crashes with SIGSEGV during runtime. If I implement my
 own version of memcpy & memset and build the executable it runs smoothly on the target. 

1. Reason why standard memset & memcpy functions crash during run time with SIGSEGV error ?

2. Can anybody share the memcpy & memset that is optimized for ARMV7 or Cortex A8 architecture ? (i.e. I have written 
one but it is not optimized for ARMV7)

3. Is memset and memcpy are part of compiler or part of glibc(or any other) library ?
Sunil Kittur(deleted)
10/06/2010 6:02 AM
post69700
Re: memcpy and memset crashes with SIGSEGV   
Are you using the armle-v7 or the armle runtime?
Only the armle-v7 runtime is EABI compliant.

memset and memcpy are in libc.so

Girisha SG wrote:
> I am compiling the code using RVCT and linking it using ld (EABI technique is used for inter operability). When I use 
the standard memcpy & memset functions in the code the executable crashes with SIGSEGV during runtime. If I implement my own version of memcpy & memset and build the executable it runs smoothly on the target. 
> 
> 1. Reason why standard memset & memcpy functions crash during run time with SIGSEGV error ?
> 
> 2. Can anybody share the memcpy & memset that is optimized for ARMV7 or Cortex A8 architecture ? (i.e. I have written one but it is not optimized for ARMV7)
> 
> 3. Is memset and memcpy are part of compiler or part of glibc(or any other) library ?
> 
> 
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post69699
>
Girisha SG
10/06/2010 6:16 AM
post69702
Re: memcpy and memset crashes with SIGSEGV   
I am using ARMv7-le variant.

I am using momentics 6.5.0
Sunil Kittur(deleted)
10/06/2010 6:27 AM
post69707
Re: memcpy and memset crashes with SIGSEGV   
Can you figure out the location in memset or memcpy where it is crashing?

Can you also dump the assembly code in your code that is calling these
functions (just to check the parameter passing etc. is OK).

I can't think of an obvious reason for why it crashes at the moment.

	Sunil.

Girisha SG wrote:
> I am using ARMv7-le variant.
> 
> I am using momentics 6.5.0
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post69702
>
Girisha SG
10/06/2010 6:36 AM
post69708
Re: memcpy and memset crashes with SIGSEGV   
Thanks, Can you let me know how can I get to know the exact location where it is failing ?

Parameters should(ofcourse it is !) be proper as same source code compiled with qcc and linked with ld works fine.
Ryan Mansfield(deleted)
10/06/2010 6:41 AM
post69710
Re: memcpy and memset crashes with SIGSEGV   
On 10-10-06 06:36 AM, Girisha SG wrote:
> Thanks, Can you let me know how can I get to know the exact location
> where it is failing ?

The debugger should stop when your program takes the sigsegv. You should 
be able to find the instruction as well as the args using the debugger.

BTW, are you sure your program is taking a sigsegv, or are you just 
seeing a crash? In which case it could be a sigbusing making unaligned 
accesses.

Regards,

Ryan Mansfield
Girisha SG
10/06/2010 7:03 AM
post69712
Re: memcpy and memset crashes with SIGSEGV   
It is becoming bit difficult for me to debug the code as it is being built with RVDS and linked with ld :(.

Yes, the error is SIGSEGV only and not SIGBUS(and hence I assume there is no alignment issue)
Ryan Mansfield(deleted)
10/06/2010 7:17 AM
post69714
Re: memcpy and memset crashes with SIGSEGV   
On 10-10-06 07:03 AM, Girisha SG wrote:
> It is becoming bit difficult for me to debug the code as it is being
> built with RVDS and linked with ld :(.

Why's that? Is gdb complaining about the debug information generated by 
armcc? Are you compiling with "-g -O0 --dwarf2"? Even without any debug 
information you should be able to set a breakpoint on an address and 
single step..

Regards,

Ryan Mansfield
Girisha SG
10/06/2010 7:27 AM
post69717
Re: memcpy and memset crashes with SIGSEGV   
with -Ono_memcpy option it is not crashing !
Girisha SG
10/06/2010 7:37 AM
post69718
Re: memcpy and memset crashes with SIGSEGV   
There are couple of problems.

1. The BSP that I am using is from QNX and it is of version 6.4.1 but EABI is supported only by momentics 6.5.0 and 
hence I have built the BSP using momentics 6.5.0. There is no build variant armv7le in 6.4.1 and hence it uses armle.

2. When I start debugging it complains about couple of .so mismatch(one of them is libc). I have linked that and copied 
them on the target before executing the program.

3. I am using IDE to debug the binary. The source in the IDE is bit different from that used with RVCT and hence it will
 directly going to disassembly.
Ryan Mansfield(deleted)
10/06/2010 8:02 AM
post69721
Re: memcpy and memset crashes with SIGSEGV   
On 10-10-06 07:37 AM, Girisha SG wrote:
> There are couple of problems.
>
> 1. The BSP that I am using is from QNX and it is of version 6.4.1 but
> EABI is supported only by momentics 6.5.0 and hence I have built the BSP
> using momentics 6.5.0. There is no build variant armv7le in 6.4.1 and
> hence it uses armle.

Do not mix armle and armle-v7 binaries! Add the armv7 variants to your 
BSP, change build file to armle-v7 and recompile it with 6.5.0 tools. 
Or ask on the BSP forum if there is going to be an 6.5.0 BSP for 
armle-v7. During the mkifs step add -vvv to make sure you are only 
pulling binaries from armle-v7 and not armle.

> 2. When I start debugging it complains about couple of .so mismatch(one
> of them is libc). I have linked that and copied them on the target
> before executing the program.

This mismatch is very serious. You need to fix it to continue debugging. 
It sounds like you may have an armle libc running on your target which 
will cause more issues for you.

> 3. I am using IDE to debug the binary. The source in the IDE is bit
> different from that used with RVCT and hence it will directly going to
> disassembly.

Can you explain what you mean about how the source is different from 
that used with RVCT? The debug information including line numbers is in 
embedded in the binary. When you debug the binary, gdb will use the 
debug information to locate the source used to compile the sources 
(unless you built it on a different host, or moved the sources) in which 
case you can tell gdb to load the source from a different location.

Even without line information you should be able to run the binary, 
catch the sigsegv and determine which instruction is responsible 
(provided you resolve the library mismatches).

Regards,

Ryan Mansfield
Girisha SG
10/06/2010 7:39 AM
post69719
Re: memcpy and memset crashes with SIGSEGV   
I am using -g -O0 but I am not using --dwarf2 option.
One more thing is if I increase the optimization level it is crashing(In this case I am using custom memcpy and memset 
functions)
Girisha SG
10/06/2010 7:54 AM
post69720
Re: memcpy and memset crashes with SIGSEGV   
I could run the  executable built with -Ono_memcpy option on the target.

One VERY IMPORTANT thing is I was expecting the performance to be better in case of source compiled with RVDS and linked
 with qcc compared to the executable built with momentics(we have observed earlier that qcc generates much better 
assembly than qcc(ofcourse gcc)) but observation is it is slower by around 17% :(

Any insight/reason whay it should be and how can I make it faster ?
Girisha SG
10/06/2010 8:19 AM
post69722
Re: memcpy and memset crashes with SIGSEGV   
1. I could not find the way by which I can change the build variant in the BSP release.

2. I have replaced the contents of armle folder with armlev7 binaries but it complains about mismatch of EABI(It says 
some thing like source is EABI 0 but xyz is EABI 5).

3. I have asked BSP forum for 6.5.0 BSP for armle-v7 release. But there is no concluding remarks.

4. [RM]:It sounds like you may have an armle libc running on your target which will cause more issues for you.
[GG]:Yes it was the case

5. The sources are modified a bit to have our own memcpy, memset, __aeabi_memcpy, __aeabi_memcpy4, __aeabi_memclr etc 
and hence the line numbers are not exactly aligned between the two cases(ofcourse this was without using -Ono_memcpy 
option :)).
Ryan Mansfield(deleted)
10/06/2010 9:21 AM
post69730
Re: memcpy and memset crashes with SIGSEGV   
On 10-10-06 08:19 AM, Girisha SG wrote:
> 1. I could not find the way by which I can change the build variant in
> the BSP release.

In the build file modify it to [virtual=armle-v7] then under the 
components add the corresponding v7 build variants directories. e.g. 
o.le.v7 or a.le.v7 or so.le.v7

> 2. I have replaced the contents of armle folder with armlev7 binaries
> but it complains about mismatch of EABI(It says some thing like source
> is EABI 0 but xyz is EABI 5).

No, don't do this. But this means you're still building the part of the 
image with armle..

> 3. I have asked BSP forum for 6.5.0 BSP for armle-v7 release. But there
> is no concluding remarks.

Which BSP is this for? Either you have to switch the BSP to armle 
yourself, or get a working BSP. Ask again in the forums. Do not proceed 
until you have a working armle-v7 BSP running on the target. If your 
target is a mismatched with ABI variants, you're going to have endless 
headaches. If you can't get a working BSP going, then have to stick with 
an armle variant, which means you will have to use gcc instead of RVDS. 
BTW, what is your motivation behind using RVDS? Your reasons must pretty 
motivating considering this is an unsupported configuration.

> 4. [RM]:It sounds like you may have an armle libc running on your target
> which will cause more issues for you.
> [GG]:Yes it was the case

It's still an issue. If you haven't changed the build file, then it 
means the libc in your image is armle.

> 5. The sources are modified a bit to have our own memcpy, memset,
> __aeabi_memcpy, __aeabi_memcpy4, __aeabi_memclr etc and hence the line
> numbers are not exactly aligned between the two cases(ofcourse this was
> without using -Ono_memcpy option :)).

Whether you provide your own implementations of functions shouldn't 
really matter. If anything you should be able to debug these as you have 
the source to these functions.

Regards,

Ryan Mansfield
Ryan Mansfield(deleted)
10/06/2010 6:26 AM
post69706
Re: memcpy and memset crashes with SIGSEGV   
On 10-10-06 05:48 AM, Girisha SG wrote:
> 3. Is memset and memcpy are part of compiler or part of glibc(or any
> other) library ?

Depends if you're using the compiler builtins or not. If you compile 
with -Ono_memcpy you will use the standard memcpy/memset in libc.

Regards,

Ryan Mansfield
Girisha SG
10/06/2010 6:38 AM
post69709
Re: memcpy and memset crashes with SIGSEGV   
Thanks, I am not passing -Ono_memcpy option to RVCT compiler during compilation and hence I assume memcpy & memset 
implemented within the compiler is getting invoked.
Ryan Mansfield(deleted)
10/06/2010 6:42 AM
post69711
Re: memcpy and memset crashes with SIGSEGV   
On 10-10-06 06:38 AM, Girisha SG wrote:
> Thanks, I am not passing -Ono_memcpy option to RVCT compiler during
> compilation and hence I assume memcpy & memset implemented within the
> compiler is getting invoked.

Does the crash happen if you compile with -Ono_memcpy?

Regards,

Ryan Mansfield
Girisha SG
10/07/2010 1:18 AM
post69864
Re: memcpy and memset crashes with SIGSEGV   
Thanks for your valuablr inputs.

1. I have modified [virtual=armle] to [virtual=armle-v7] in the build file and I was able to build the BSP. But when I 
use the same image on the target I am getting the following errors.

cpu_startnext: cpu0 -> fe04a9a8
VFPv3: fpsid=410330c1
coproc_attach(10): replacing fe06e32c with fe06db68
coproc_attach(11): replacing fe06e32c with fe06db68
Welcome to QNX Neutrino 6.4.1 on the Texas Instruments OMAP3530 (ARMv7 Cortex-A8 core) EVM Board
Unable to start "resource_seed" (2)
Unable to start "devc-seromap" (2)
Unable to access "/dev/ser1" (2)
Unable to access "/dev/ser1" (2)
Starting on-board ethernet with TCP/IP stack...
Unable to access "/dev/io-net/en0" (2)
ifconfig: SIOCGIFFLAGS en0: No such device or address
Unable to start "fs-etfs-omap3530" (2)
Unable to start "fs-etfs-omap3530" (2)
starting I2C driver...
Unable to start "i2c-omap35xx" (2)
Unable to access "/dev/i2c0" (2)
Configure power management chip
Unable to start "pmic_tw4030_cfg" (2)
starting SPI driver...
Unable to start "spi-master" (2)
Unable to access "/dev/spi0" (2)
Starting audio driver...
Starting USB OTG Host driver...
DLL Error Library cannot be found
 FAILED  - io_usb_dlopen
unable to load dll devu-omap3530-mg
Starting MMC/SD driver...
Unable to start "devb-mmcsd-mistral" (2)
Starting Graphics driver...
Could not initialize device "vid=0,did=0": No such file or directory
Check 'sloginfo' output for more details
io-display failed to initialise
Unable to access "/dev/io-display" (2)
Starting INETD...
sh: No controlling tty (open /dev/tty: No such device or address)
sh: warning: won't have full job control

2. The BSP is for OMAP3530 mistral EVM.
Earlier we have observed that the performance of RVDS is much better(i.e. it is generating the best assebmly code and 
has less foot print) but currently with EABI & RVDS I am observing the executabl is 17% slower than the one that is 
built using momentics :( .... Dont know the cause yet.

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems