Skip to main content

Alignment trap: cvm (4372) PC=0x45c4ff5c Instr=0xe5893014 Address=0xbec363d

10 replies [Last post]
jeconnolly
Offline
Joined: 2008-03-30

We've recently built pMEA CDC PP for an i.mx31 device running Linux 2.6.24.4. The distribution is poky, maintained by Openhand. Build flags are below. I've been seeing some alignment trap problems recently that are a bit disconcerting and I'm trying to find out from where they arise.

Here is a code sample that is less than informative, but I thought it couldn't hurt:

LogService ls = LogServiceUtil.getLogService(context);

advRef = context.getServiceReference(JSLP_SERVICE_NAME);

if (advRef != null) {
//advertiser = (Advertiser) context.getService(advRef);
String port = System.getProperty("org.osgi.service.http.port");
if (port != null) {
portString = ":" + port;
}

sURL = new ServiceURL("service:bug:/" + advertiser.getMyIP() + portString, ServiceURL.LIFETIME_PERMANENT);

try {
advertiser.register(sURL, null);
} catch (ServiceLocationException e) {
ls.log(LogService.LOG_ERROR, e.getMessage());
e.printStackTrace();
}

I had originally thought that it may have had something to do with object serialization, but as I read through this post: http://forums.java.net/jive/thread.jspa?messageID=277923 it seems that the serialization discussion was limited to resolving the NoClassDefFoundExceptions he was seeing.

There was change of toolchain from old distribution (LTIB) to our new (Poky), and the gcc flags are listed below as well. I have a feeling that this is the core issue. Also, note that JIT is enabled, and the Alignment trap occurs with or without JIT enabled at runtime.

Thanks for any help.

-John

pMEA build flags

AWT_IMPLEMENTATION=peer_based
AWT_PEERSET=qt
CVM_AGENTLIB=false
CVM_AOT=false
CVM_CCM_COLLECT_STATS=false
CVM_CLASSLIB_JCOV=false
CVM_CLASSLOADING=true
CVM_CREATE_RTJAR=false
CVM_CSTACKANALYSIS=false
CVM_DEBUG=false
CVM_DEBUG_ASSERTS=false
CVM_DEBUG_CLASSINFO=false
CVM_DEBUG_DUMPSTACK=false
CVM_DEBUG_STACKTRACES=true
CVM_DUAL_STACK=false
CVM_DYNAMIC_LINKING=true
CVM_EMBEDDED_HOOK=false
CVM_FORCE_HARD_FLOAT=false
CVM_GCCHOICE=generational
CVM_GCOV=false
CVM_GPROF=false
CVM_GPROF_NO_CALLGRAPH=true
CVM_HOST=x86_64-Ubuntu-linux
CVM_IAI_OPT_ALL=true
CVM_INCLUDE_COMMCONNECTION=false
CVM_INSPECTOR=false
CVM_INSTRUCTION_COUNTING=false
CVM_INTERPRETER_LOOP=Standard
CVM_JAVAC_DEBUG=false
CVM_JIT=true
CVM_JIT_CODE_SCHED=false
CVM_JIT_COLLECT_STATS=
CVM_JIT_COPY_CCMCODE_TO_CODECACHE=true
CVM_JIT_DEBUG=false
CVM_JIT_ESTIMATE_COMPILATION_SPEED=false
CVM_JIT_PMI=false
CVM_JIT_PROFILE=false
CVM_JIT_REGISTER_LOCALS=true
CVM_JIT_USE_FP_HARDWARE=false
CVM_JVMPI=false
CVM_JVMPI_TRACE_INSTRUCTION=false
CVM_JVMTI=false
CVM_JVMTI_ROM=false
CVM_KNI=false
CVM_LVM=false
CVM_MP_SAFE=false
CVM_MTASK=false
CVM_NO_CODE_COMPACTION=false
CVM_OPTIMIZED=true
CVM_PRELOAD_LIB=false
CVM_PRELOAD_TEST=false
CVM_PRODUCT=premium
CVM_REFLECT=true
CVM_SERIALIZATION=true
CVM_SPLIT_VERIFY=false
CVM_STATICLINK_LIBS=false
CVM_SYMBOLS=false
CVM_TEST_GC=false
CVM_TEST_GENERATION_GC=false
CVM_THREAD_SUSPENSION=false
CVM_TIMESTAMPING=true
CVM_TRACE=false
CVM_TRACE_JIT=false
CVM_USE_CVM_MEMALIGN=false
CVM_USE_MEM_MGR=false
CVM_USE_NATIVE_TOOLS=false
CVM_VERIFY_HEAP=false
CVM_XRUN=false
EXCLUDE_XLET_RUNNER=false
J2ME_CLASSLIB=personal
OPT_PKGS=
USE_AAPCS=true
USE_CDC_COM=
USE_GCI=false
USE_JUMP=false
USE_MIDP=false

Target: arm-poky-linux-gnueabi
Configured with: build/tmp/work/armv5te-poky-linux-gnueabi/gcc-cross-4.1.2-r5/gcc-4.1.2/configure
--build=i686-linux
--host=i686-linux
--target=arm-poky-linux-gnueabi
--prefix=build/tmp/cross
--exec_prefix=build/tmp/cross
--bindir=build/tmp/cross/bin
--sbindir=build/tmp/cross/bin
--libexecdir=build/tmp/cross/libexec
--datadir=build/tmp/cross/share
--sysconfdir=build/tmp/cross/etc
--sharedstatedir=build/tmp/cross/com
--localstatedir=build/tmp/cross/var
--libdir=build/tmp/cross/lib
--includedir=build/tmp/cross/include
--oldincludedir=build/tmp/cross/include
--infodir=build/tmp/cross/share/info
--mandir=build/tmp/cross/share/man
--enable-mainainer-mode
--with-gnu-ld
--enable-shared
--enable-target-optspace
--enable-languages=c,c++
--enable-threads=posix
--enable-multilib
--enable-c99
--enable-long-long
--enable-symvers=gnu
--enable-libstdcxx-pch
--program-prefix=arm-poky-linux-gnueabi-
--with-local-prefix=build/tmp/staging/arm-poky-linux-gnueabi/usr
--with-gxx-include-dir=build/tmp/staging/arm-poky-linux-gnueabi//usr/include/c++
--with-sysroot=build/tmp/staging/arm-poky-linux-gnueabi
--with-build-sysroot=build/tmp/staging/arm-poky-linux-gnueabi
--enable-__cxa_atexit
--with-float=soft
--disable-libssp
--disable-libunwind-exceptions
--with-mpfr=build/tmp/staging/i686-linux/usr
Thread model: posix
gcc version 4.1.2

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cjplummer
Offline
Joined: 2006-10-16

A colleague pointed out that there is a "char hostname[MAXHOSTNAMELEN+1] declaration at the start of the function, so this is what results in buf and buf2 being unaligned. However, gethostbyname_r has no alignment requirements for the "char *buf" argument passed in, so I think you've actually uncovered a bug in your gethostbyname_r implementation.

However, since this seems to be somewhat common, a fix in PMEA is appropriate. Rather than relying on the gcc aligned attribute, which limits your compiler choice, it might be best to force alignment by other means. Try the following. If it works for you, I will commit it sometime early next week.

Chris

[I apologize in advance for the formatting, which I know java.net will mess up.]

Index: src/linux/native/java/net/Inet4AddressImpl_md.c
===================================================================
--- src/linux/native/java/net/Inet4AddressImpl_md.c (revision 13706)
+++ src/linux/native/java/net/Inet4AddressImpl_md.c (working copy)
@@ -81,23 +81,29 @@
* We use thread-safe system calls.
*/
#endif /* __linux__ */
- struct hostent res, res2, *hp;
- char buf[HENT_BUF_SIZE];
- char buf2[HENT_BUF_SIZE];
+ struct hostent *hp;
+ struct {
+ struct hostent res;
+ char buf[HENT_BUF_SIZE];
+ } buffer, buffer2;
int h_error=0;

#ifdef __GLIBC__
- gethostbyname_r(hostname, &res, buf, sizeof(buf), &hp, &h_error);
+ gethostbyname_r(hostname, &buffer.res, bufer.buf,
+ sizeof(buffer.buf), &hp, &h_error);
#else
- hp = gethostbyname_r(hostname, &res, buf, sizeof(buf), &h_error);
+ hp = gethostbyname_r(hostname, &buffer.res, bufer.buf,
+ sizeof(buffer.buf), &h_error);
#endif
if (hp) {
#ifdef __GLIBC__
gethostbyaddr_r(hp->h_addr, hp->h_length, AF_INET,
- &res2, buf2, sizeof(buf2), &hp, &h_error);
+ &buffer2.res, buffer2.buf,
+ sizeof(buffer2.buf), &hp, &h_error);
#else
hp = gethostbyaddr_r(hp->h_addr, hp->h_length, AF_INET,
- &res2, buf2, sizeof(buf2), &h_error);
+ &buffer2.res, buffer2.buf,
+ sizeof(buffer2.buf), &h_error);
#endif
if (hp) {
/*

cjplummer
Offline
Joined: 2006-10-16

Let me know if the following solves your alignment trap problem:

Index: src/linux/native/java/net/Inet4AddressImpl_md.c
===================================================================
--- src/linux/native/java/net/Inet4AddressImpl_md.c (revision 13712)
+++ src/linux/native/java/net/Inet4AddressImpl_md.c (working copy)
@@ -82,8 +82,8 @@
*/
#endif /* __linux__ */
struct hostent res, res2, *hp;
- char buf[HENT_BUF_SIZE];
- char buf2[HENT_BUF_SIZE];
+ char buf[HENT_BUF_SIZE] __attribute__ ((aligned));
+ char buf2[HENT_BUF_SIZE] __attribute__ ((aligned));
int h_error=0;

#ifdef __GLIBC__

jeconnolly
Offline
Joined: 2008-03-30

The patch worked. :) Thanks a lot for your help Chris and Hinkmond. Very impressive how quickly you tracked that down.

We'll likely move this patch up into the jalimo recipe for pMEA. Thanks again.

cjplummer
Offline
Joined: 2006-10-16

Well, actually I didn't track it down. You got lucky because one of our Engineering Services guys recognized the "alignment trap" message and already had a fix. However, we don't quite understand why the fix helps, because the two arrays should already be 4 byte aligned. Maybe you could look at the generated code without and without the fix to see what is different. We no longer have a platform that reproduces this problem, so we can't check for ourselves.

Chris

ken_gilmer
Offline
Joined: 2007-01-19

We'll check out the source difference, but we'll also work on getting you a BUG. :)

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> We'll check out the source difference, but we'll also work on getting you a BUG. :)
>

Hey, now _that's_ the real solution. :-) If you get us a couple BUGs,
we can even ask our QA to keep one in our lab for regression testing
with our continuous builds.

(That's all in your best interest of course... ;-) would also be cool
for us to have a couple BUGs in our group) :-)

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> We've recently built pMEA CDC PP for an i.mx31 device running Linux 2.6.24.4. The distribution is poky, maintained by Openhand. Build flags are below. I've been seeing some alignment trap problems recently that are a bit disconcerting and I'm trying to find out from where they arise.
> ...
>
> I had originally thought that it may have had something to do with object serialization, but as I read through this post: http://forums.java.net/jive/thread.jspa?messageID=277923 it seems that the serialization discussion was limited to resolving the NoClassDefFoundExceptions he was seeing.
>
> There was change of toolchain from old distribution (LTIB) to our new (Poky), and the gcc flags are listed below as well. I have a feeling that this is the core issue. Also, note that JIT is enabled, and the Alignment trap occurs with or without JIT enabled at runtime.
>

Hi John,

What do you mean by "alignment trap" problems? Do you get an assertion
failure in the VM code? Or, better yet, what is the exact output (error
message) you are seeing?

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

cjplummer
Offline
Joined: 2006-10-16

What do you mean by alignment traps? Can you show a gdb backtrace when this happens?

Also, are you sure USE_AAPCS=true is correct for your platform. To be sure, build with CVM_DEBUG=true CVM_JIT=true. This should cause cvm to assert on startup if USE_AAPCS is not set properly.

Chris

jeconnolly
Offline
Joined: 2008-03-30

Specifically, the error message I get are kernel traps:

[83635.340000] Alignment trap: cvm (4372) PC=0x45c4ff5c Instr=0xe5893014 Address=0xbec363db FSR 0x811
[83635.350000] Alignment trap: cvm (4372) PC=0x45c4ff60 Instr=0xe5899010 Address=0xbec363d7 FSR 0x811
[83635.360000] Alignment trap: cvm (4372) PC=0x000e2308 Instr=0xe59c0000 Address=0xbec363d7 FSR 0x011
[83635.370000] Alignment trap: cvm (4372) PC=0x45c4ff5c Instr=0xe5893014 Address=0xbec35fdb FSR 0x811
[83635.380000] Alignment trap: cvm (4372) PC=0x45c4ff60 Instr=0xe5899010 Address=0xbec35fd7 FSR 0x811
[83635.380000] Alignment trap: cvm (4372) PC=0x45c50278 Instr=0xe59e1000 Address=0xbec35fd7 FSR 0x011
[83811.500000] Alignment trap: cvm (4432) PC=0x429a4f5c Instr=0xe5893014 Address=0xbe95f3bb FSR 0x811

These errors are displayed with dmesg as cvm is running the code mentioned before. I'll do a gdb backtrace, but I'm deferring to your interactions with ken gilmer with regard to using AAPCS:
http://forums.java.net/jive/message.jspa?messageID=201217

I'm working on the BUG. ;D

I'll kick off a build now with CVM_DEBUG=true and CVM_JIT=true to check it out. Thanks for your prompt replies Hinkmond and Chris.

cjplummer
Offline
Joined: 2006-10-16

> Specifically, the error message I get are kernel
> traps:
>
> [83635.340000] Alignment trap: cvm (4372)
> PC=0x45c4ff5c Instr=0xe5893014 Address=0xbec363db FSR
> 0x811
> [83635.350000] Alignment trap: cvm (4372)
> PC=0x45c4ff60 Instr=0xe5899010 Address=0xbec363d7 FSR
> 0x811
> [83635.360000] Alignment trap: cvm (4372)
> PC=0x000e2308 Instr=0xe59c0000 Address=0xbec363d7 FSR
> 0x011
> [83635.370000] Alignment trap: cvm (4372)
> PC=0x45c4ff5c Instr=0xe5893014 Address=0xbec35fdb FSR
> 0x811
> [83635.380000] Alignment trap: cvm (4372)
> PC=0x45c4ff60 Instr=0xe5899010 Address=0xbec35fd7 FSR
> 0x811
> [83635.380000] Alignment trap: cvm (4372)
> PC=0x45c50278 Instr=0xe59e1000 Address=0xbec35fd7 FSR
> 0x011
> [83811.500000] Alignment trap: cvm (4432)
> PC=0x429a4f5c Instr=0xe5893014 Address=0xbe95f3bb FSR
> 0x811
>
> These errors are displayed with dmesg as cvm is
> running the code mentioned before.

These are all pretty basic ldr and str instructions. They all have an Address field that is invalid (not 4-byte aligned). Most likely it is just garbage.

> I'll do a gdb backtrace,

This won't help given what I now know from the above info. Actually if you turn off the JIT maybe it will be useful, so go ahead and give it a try. However, hopefully the problem is with AAPCS and changing the USE_AAPCS setting will fix it.

> but I'm deferring to your interactions
> with ken gilmer with regard to using AAPCS:
> http://forums.java.net/jive/message.jspa?messageID=201217
>
Can you be more specific about the message? The link just takes me to the start of a very long thread.

Chris