On Thu, 16 Dec 2004, Christian [iso-8859-1] Røsnes wrote: > On Thursday 16 December 2004 15:56, James Yonan wrote: > > On Thu, 16 Dec 2004, Christian [iso-8859-1] Røsnes wrote: > > > > > > I can connect each endpoint, but when I try to ping either endpoint of > > > the vpn tunnel, the OpenVPN server dumps core and dies: > > > > > > pid 17868 (openvpn): unaligned access: va=0x12012f82f pc=0x120023900 > > > ra=0x1200238f4 op=ldl > > > Bus error (core dumped) > > > > > > Using gdb, I find: > > > > > > # gdb /usr/local/sbin/openvpn openvpn.core > > > GNU gdb 4.16.1 > > > ... > > > This GDB was configured as "alpha-unknown-openbsd3.5"... > > > Core was generated by `openvpn'. > > > > > > > > > Program terminated with signal 10, Bus error. > > > #0 0x120023904 in mroute_extract_addr_from_packet > > > (src=0x1ffffb220, dest=0x1ffffb208, buf=0x1, tunnel_type=-20292) at > > > mroute.c:113 > > > 113 memcpy (src->addr, &ip->saddr, 4); > > > > > > > > > I think my system choke on the 'ip->saddr' address in the memcpy > > > statement. > > > > That's strange that it would hit an alignment fault on a memcpy. memcpy > > is supposed to operate at byte granularity. The whole reason I use memcpy > > here in the first place is to prevent alignment faults on the legacy > > processors that have trouble with them. > > > > Now on the other hand if the compiler tried to optimize the memcpy into a > > 32 bit move instruction, then there will be problems because ip is not > > aligned correctly for that. > > > > What assembly code is being generated for the memcpy? > > > > Try, just as a test, compiling without optimization, and see if it affects > > the code generated for the memcpy. > > > > James > > Yes, removing -O2 from CFLAGS, and recompiling fixed the core dump problem > when pinging (although I get no answer, but that is maybe something related > to my configuration). > Then, setting -02 and recompiling after that brought the core dump back > when pinging. > > So, the optimization seems to cause this somehow. > I'll leave -O2 off for now.
Building without optimization might be overkill. Try keeping -O2 on, but add -fno-builtin-memcpy to eliminate the inlining of memcpy. See also this bug report which looks like an exact match to what your are seeing: http://gcc.gnu.org/ml/gcc-bugs/2000-03/msg00155.html It looks like it might be possible to work around the issue with the right intermediate casting in mroute.c. James
