Re: cvsup broken on amd64?

From: Oliver Lehmann <lehmann_at_ans-netz.de>
Date: Fri, 09 Sep 2011 16:19:42 +0200
Kostik Belousov <kostikbel_at_gmail.com> wrote:

> I do not know, I was curious about 'illegal instruction' signal,
> which would indicate a problem in the compilation environment.
> Now you get segmentation violation, that is usually caused by a bug in
> the program itself.

running it outside gdb still results in an 'illegal instruction' error.
Why it gets to "segmentation violation" inside gdb I just don't know.

nudel# ./client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile
Connected to cvsup.de.FreeBSD.org
Updating collection src-all/cvs
  Edit src/crypto/openssl/ssl/s3_lib.c
Illegal instruction (core dumped)
nudel# gdb ./client/FBSD_AMD64/cvsup cvsup.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `cvsup'.
Program terminated with signal 4, Illegal instruction.
#0  0x00000000004d24c6 in tzload ()
(gdb) bt
#0  0x00000000004d24c6 in tzload ()
#1  0x00000000004d1f89 in tzparse ()
#2  0x00000000004d2c27 in tzload ()
#3  0x00000000004d2e36 in gmtload ()
#4  0x00000000004eac15 in _once ()
#5  0x00000000004d1c8b in gmtsub ()
#6  0x00000000004d33e9 in gmtime ()
#7  0x00000000004a3d4a in Date__FromTime (M3_CtKayy_t=1314794791,  
M3_Ab1PrR_z=0x7ed538, M3_D5xROs__result=0x934c08) at DateBsd.m3:31
#8  0x00000000004387d7 in RCSDate__FromTime (M3_CtKayy_t=1314794791)  
at RCSDate.m3:54
#9  0x00000000004467ba in RCSFile__Import (M3_Bd56fi_p=0x9d9008,  
M3_Bd56fi_revNum=0x9d87c8, M3_Bd56fi_author=0x763020,  
M3_Bd56fi_state=0x763040,
     M3_AcxOUs_logLines=12) at RCSFile.m3:413
#10 0x00000000004077de in CheckoutUpdater__Update  
(M3_CTVCUv_self=0x9d8980, M3_CzVV2w_sfr=0x7ff2e0,  
M3_Bd56fi_name=0x9d8788, M3_AicXUJ_toAttic=0 '\0',
     M3_DsoVVS_proto=0x7f74a8, M3_AeHwgK_trace=0x7f8710,  
M3_EkTcCb_protoRd=0x9d05b8, M3_BxxOH1_wr=0x9d8e98,  
M3_AQMw24_status=0x935f48)
     at CheckoutUpdater.m3:111
#11 0x0000000000416ab4 in Updater__UpdateFile  
(M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0,  
M3_Bd56fi_name=0x9d8788, M3_AicXUJ_toAttic=0 '\0',
     M3_DMoNGc_fup=0x9d8980, M3_AicXUJ_isFixup=0 '\0') at Updater.m3:641
#12 0x00000000004155ce in Updater__UpdateCollection  
(M3_DBUV6k_self=0x7fee38, M3_CzVV2w_sfr=0x7ff2e0, M3_AicXUJ_isFixups=0  
'\0') at Updater.m3:458
#13 0x0000000000412baf in Updater__UpdateBatch  
(M3_DBUV6k_self=0x7fee38, M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151
#14 0x000000000041268a in Updater__Apply (M3_DBUV6k_self=0x7fee38) at  
Updater.m3:90
#15 0x000000000049d290 in ThreadPosix__DetermineContext  
(M3_AJWxb1_oldSP=0x7edfd0) at ThreadPosix.m3:1127
#16 0x000000000048d34d in RTCollector__LongAlloc  
(M3_Cwb5VA_dataSize=4337239, M3_Cwb5VA_dataAlignment=8577024,  
M3_AOtCKl_currentPtr=0x7f8,
     M3_AOtCKl_currentBoundary=0x76c8f8, M3_CCsHD8_currentPage=0x0,  
M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=144 '\220',  
M3_AicXUJ_pure=120 'x')
     at RTCollector.m3:1530
#17 0x00007fffffffc428 in ?? ()
#18 0x00007fffffffd990 in ?? ()
#19 0x00007fffffffda78 in ?? ()
#20 0x00007fffffffda58 in ?? ()
#21 0x0000000000000000 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x00001fa00000037f in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x00000000007f76c0 in ?? ()
#26 0x00000000007f76c0 in ?? ()
#27 0x0000000000492699 in RTMisc__Copy (M3_AJWxb1_src=Cannot access  
memory at address 0xfffffffffffffffb
) at RTMisc.m3:19
Previous frame inner to this frame (corrupt stack?)
(gdb)
Received on Fri Sep 09 2011 - 12:19:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:17 UTC