Bug#402745: cvs Terminated with fatal signal 10
On Mon, Dec 18, 2006 at 10:50:23AM -0300, Martin Marques wrote: On Mon, 18 Dec 2006 13:21:06 +, Steve McIntyre [EMAIL PROTECTED] wrote: I haven't uploaded yet; there's another issue with inetd configuration that needs fixing as well I'm afraid. I'm expecting a fix for that ASAP. Even then, it'll take a couple of days to migrate to testing, and I'll ask you to check the version in unstable for me if that's possible. Jurij's change is simply to lower the amount of compiler optimisation, which might have been an option if the real cause of your problem hadn't been found. Sorry then. :-( I revert to Jurijs CVS for now so we can keep working. Tell me when you have a version to test on. There's a new version in Incoming right now that should hopefully work for you. Please let me know ASAP if you still have any problems. Apologies for the delay, the other bug I needed to fix needed a lot of testing too. :-( -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You can't barbecue lettuce! -- Ellie Crane signature.asc Description: Digital signature
Bug#402745: cvs Terminated with fatal signal 10
On Fri, 15 Dec 2006 15:57:48 +, Steve McIntyre [EMAIL PROTECTED] wrote: On Fri, Dec 15, 2006 at 02:02:58AM +0100, Julien Cristau wrote: I can confirm that the attached patch fixes this problem for me. Excellent, thanks for the help in tracking this down, Julien and Samuel! I'll add this and upload this weekend, and clearly upstream need to know too. Steve, this didn't work. Updated the last cvs from testing about 2 days ago and I'm getting signal 10 again. Why not look at Jurij's packages which did work OK? http://www.wooyd.org/debian/cvs -- - Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática| '@' || 'unl.edu.ar'; Universidad Nacional| DBA, Programador, del Litoral | Administrador -
Bug#402745: cvs Terminated with fatal signal 10
On Mon, Dec 18, 2006 at 10:05:43AM -0300, Martin Marques wrote: On Fri, 15 Dec 2006 15:57:48 +, Steve McIntyre [EMAIL PROTECTED] wrote: On Fri, Dec 15, 2006 at 02:02:58AM +0100, Julien Cristau wrote: I can confirm that the attached patch fixes this problem for me. Excellent, thanks for the help in tracking this down, Julien and Samuel! I'll add this and upload this weekend, and clearly upstream need to know too. Steve, this didn't work. Updated the last cvs from testing about 2 days ago and I'm getting signal 10 again. Why not look at Jurij's packages which did work OK? http://www.wooyd.org/debian/cvs I haven't uploaded yet; there's another issue with inetd configuration that needs fixing as well I'm afraid. I'm expecting a fix for that ASAP. Even then, it'll take a couple of days to migrate to testing, and I'll ask you to check the version in unstable for me if that's possible. Jurij's change is simply to lower the amount of compiler optimisation, which might have been an option if the real cause of your problem hadn't been found. Thanks, -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402745: cvs Terminated with fatal signal 10
On Mon, 18 Dec 2006 13:21:06 +, Steve McIntyre [EMAIL PROTECTED] wrote: I haven't uploaded yet; there's another issue with inetd configuration that needs fixing as well I'm afraid. I'm expecting a fix for that ASAP. Even then, it'll take a couple of days to migrate to testing, and I'll ask you to check the version in unstable for me if that's possible. Jurij's change is simply to lower the amount of compiler optimisation, which might have been an option if the real cause of your problem hadn't been found. Sorry then. :-( I revert to Jurijs CVS for now so we can keep working. Tell me when you have a version to test on. -- - Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática| '@' || 'unl.edu.ar'; Universidad Nacional| DBA, Programador, del Litoral | Administrador -
Bug#402745: cvs Terminated with fatal signal 10
On Fri, Dec 15, 2006 at 02:02:58AM +0100, Julien Cristau wrote: On Fri, Dec 15, 2006 at 00:59:38 +0100, Samuel Thibault wrote: Hi, Looks like the culprit line is update.c:726. unsigned char checksum[16]; An unsigned char[16] won't necessarily be aligned by gcc. However, it is used as a checksum buffer, on which md5_read_ctx() performs 32bit operations. Hence the SIGBUS on sparc. I guess the best correction would be to just express the correct type: md5_uint32 checksum[4]; I can confirm that the attached patch fixes this problem for me. Excellent, thanks for the help in tracking this down, Julien and Samuel! I'll add this and upload this weekend, and clearly upstream need to know too. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You raise the blade, you make the change... You re-arrange me 'til I'm sane... signature.asc Description: Digital signature
Bug#402745: cvs Terminated with fatal signal 10
On Tue, Dec 12, 2006 at 22:44:21 -0800, Jurij Smakov wrote: Hi Martin, Can you please try doing the same debugging trick after installing the cvs package from http://www.wooyd.org/debian/cvs It contains the non-stripped cvs binary. And type 'backtrace' or 'bt' at the gdb prompt after it loads up the core file, and attach the output to the bug. I reproduced this bug (I had seen it a while ago, but never took the time to debug it), and got a core dump (without debug symbols). Then I installed your packages and reran cvs up to get a useful core file, but this time it didn't fail :( Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402745: cvs Terminated with fatal signal 10
On Thu, 14 Dec 2006 21:36:51 +0100, Julien Cristau [EMAIL PROTECTED] wrote: On Tue, Dec 12, 2006 at 22:44:21 -0800, Jurij Smakov wrote: Hi Martin, Can you please try doing the same debugging trick after installing the cvs package from http://www.wooyd.org/debian/cvs It contains the non-stripped cvs binary. And type 'backtrace' or 'bt' at the gdb prompt after it loads up the core file, and attach the output to the bug. I reproduced this bug (I had seen it a while ago, but never took the time to debug it), and got a core dump (without debug symbols). Then I installed your packages and reran cvs up to get a useful core file, but this time it didn't fail :( Julien you are right. I tested cvs with the testing version and it failed. I installed the version from Jurij's repository and now it works OK! Can we check what's diferent between the debian testing version and the one Jurij compiled? -- - Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática| '@' || 'unl.edu.ar'; Universidad Nacional| DBA, Programador, del Litoral | Administrador -
Bug#402745: cvs Terminated with fatal signal 10
On Thu, Dec 14, 2006 at 21:36:51 +0100, Julien Cristau wrote: I reproduced this bug (I had seen it a while ago, but never took the time to debug it), and got a core dump (without debug symbols). Then I installed your packages and reran cvs up to get a useful core file, but this time it didn't fail :( This is weird. cvs built with -O0 -g seems to work fine cvs built with -O2 -g gets a sigbus, but when running gdb on the core file I get the following: /build/buildd/gdb-6.4.90.dfsg/gdb/regcache.c:926: internal-error: register_offset_hack: Assertion `regnum = 0 regnum descr-nr_cooked_registers' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. In any case, gdb gives the following backtrace: #0 0x00081e00 in md5_read_ctx (ctx= ) at md5.c:91 #1 0x0006c7c4 in update_fileproc (callerdat=value optimized out, finfo=0xff12532d) at update.c:1644 #2 0x00055e90 in do_file_proc (p=0x0, closure=0xff125494) at recurse.c:959 #3 0x0002fbb0 in walklist (list=value optimized out, proc=0xff1254b4, closure=0xce918) at hash.c:419 #4 0x00054a14 in do_recursion (frame=0xce750) at recurse.c:847 #5 0x00055904 in do_dir_proc (p=value optimized out, closure=0xcd3c8) at recurse.c:1232 #6 0x0002fbb0 in walklist (list=value optimized out, proc=0xff12564c, closure=0x994d0) at hash.c:419 #7 0x000548fc in do_recursion (frame=0xcdf78) at recurse.c:877 #8 0x00055904 in do_dir_proc (p=value optimized out, closure=0xcca92) at recurse.c:1232 #9 0x0002fbb0 in walklist (list=value optimized out, proc=0xff1257ec, closure=0x994d0) at hash.c:419 #10 0x000548fc in do_recursion (frame=0xcaed8) at recurse.c:877 #11 0x000550fc in start_recursion (fileproc=value optimized out, filesdoneproc=0x994d0 __PRETTY_FUNCTION__.8742+984, direntproc=0x1, dirleaveproc=0xff12592c, callerdat=0x1bd38, argc=0, argv= /build/buildd/gdb-6.4.90.dfsg/gdb/regcache.c:175: internal-error: register_size: Assertion `regnum = 0 regnum (NUM_REGS + NUM_PSEUDO_REGS)' failed. A problem internal to GDB has been detected, Hope this helps, and let me know if I can do any more debugging. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402745: cvs Terminated with fatal signal 10
Hi, Looks like the culprit line is update.c:726. unsigned char checksum[16]; An unsigned char[16] won't necessarily be aligned by gcc. However, it is used as a checksum buffer, on which md5_read_ctx() performs 32bit operations. Hence the SIGBUS on sparc. I guess the best correction would be to just express the correct type: md5_uint32 checksum[4]; And gcc will correctly align that if needed by the architecture. The bad news are that there are probably other places like this... Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402745: cvs Terminated with fatal signal 10
On Fri, Dec 15, 2006 at 00:59:38 +0100, Samuel Thibault wrote:
Hi,
Looks like the culprit line is update.c:726.
unsigned char checksum[16];
An unsigned char[16] won't necessarily be aligned by gcc. However, it
is used as a checksum buffer, on which md5_read_ctx() performs 32bit
operations. Hence the SIGBUS on sparc. I guess the best correction
would be to just express the correct type:
md5_uint32 checksum[4];
I can confirm that the attached patch fixes this problem for me.
Cheers,
Julien
diff -u cvs-1.12.13/debian/changelog cvs-1.12.13/debian/changelog
--- cvs-1.12.13/debian/changelog
+++ cvs-1.12.13/debian/changelog
@@ -1,3 +1,10 @@
+cvs (1:1.12.13-5.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix unaligned access causing SIGBUS on sparc (closes: #402745).
+
+ -- Julien Cristau [EMAIL PROTECTED] Fri, 15 Dec 2006 01:39:13 +0100
+
cvs (1:1.12.13-5) unstable; urgency=low
* Major update for l10n before etch, thanks to Christian Perrier.
only in patch2:
unchanged:
--- cvs-1.12.13.orig/debian/patches/98_fix_sparc_sigbus.diff
+++ cvs-1.12.13/debian/patches/98_fix_sparc_sigbus.diff
@@ -0,0 +1,30 @@
+diff -Nru cvs-1.12.13.orig/src/update.c cvs-1.12.13/src/update.c
+--- cvs-1.12.13.orig/src/update.c 2005-09-22 20:49:17.0 +0200
cvs-1.12.13/src/update.c 2006-12-15 01:35:54.0 +0100
+@@ -58,7 +58,7 @@
+ static int patch_file (struct file_info *finfo,
+Vers_TS *vers_ts,
+int *docheckout, struct stat *file_info,
+- unsigned char *checksum);
++ md5_uint32 *checksum);
+ static void patch_file_write (void *, const char *, size_t);
+ #endif
+ static int merge_file (struct file_info *finfo, Vers_TS *vers);
+@@ -723,7 +723,7 @@
+ {
+ int docheckout;
+ struct stat file_info;
+- unsigned char checksum[16];
++ md5_uint32 checksum[4];
+
+ retval = patch_file (finfo,
+vers, docheckout,
+@@ -1511,7 +1511,7 @@
+ */
+ static int
+ patch_file (struct file_info *finfo, Vers_TS *vers_ts, int *docheckout,
+- struct stat *file_info, unsigned char *checksum)
++ struct stat *file_info, md5_uint32 *checksum)
+ {
+ char *backup;
+ char *file1;
signature.asc
Description: Digital signature
Bug#402745: cvs Terminated with fatal signal 10
Package: cvs Version: 1:1.12.13-5 Severity: normal I have CVS configured to work with ssh as an external autentication mecanism. I just passed cvs from stable (sarge) to testing and I'm getting this error. When I try to update a repository remotly I get this: $ cvs -q up ? SISTEMA.csv ? javascript/prueba.html ? javascript/windowCargo.js Terminated with fatal signal 10 I the cvs tree (/var/lib/cvs/planta) I can find lock files related to the update I just executed: #cvs.rfl.bugs.16487 but with no proceses with id 16487. If I downgrade to stable (sarge) cvs works ok, but in testing I get these errors constantly. The repository in question is not been used by anybdy else. I'm the only one accessing it. Now, if I try to execute the same line on the local server, but still using ssh as the external autentication method, it works ok, even without removing the lock files that in the cvs directory. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (80, 'testing'), (50, 'unstable') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-sparc64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages cvs depends on: ii debconf [debconf-2.0]1.5.8 Debian configuration management sy ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libpam-runtime 0.79-4 Runtime support for the PAM librar ii libpam0g 0.79-4 Pluggable Authentication Modules l ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages cvs recommends: ii emacs21 [info-browser] 21.4a-6 The GNU Emacs editor ii info [info-browser] 4.8.dfsg.1-4Standalone GNU Info documentation ii konqueror [info-browser] 4:3.3.2-1sarge3 KDE's advanced File Manager, Web B ii netbase 4.27Basic TCP/IP networking system -- debconf information: cvs/pserver_repos_individual: true cvs/pserver_setspawnlimit: false cvs/rotatekeep: 7 * cvs/badrepositories: ignore cvs/pserver_warning: cvs/rotatekeep_individual: 7 cvs/pserver_repos: all * cvs/pserver: false cvs/cvs_conf_is_dead: * cvs/repositories: /var/lib/cvs cvs/rotatekeep_nondefault: no cvs/rotate_individual: true cvs/pserver_spawnlimit: 400 * cvs/rotatehistory: no -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402745: cvs Terminated with fatal signal 10
On Tue, 12 Dec 2006 14:55:41 +, Steve McIntyre [EMAIL PROTECTED] wrote: On Tue, Dec 12, 2006 at 09:43:19AM -0300, Martin Marques wrote: Hmmm. Signal 10 is SIGBUS, which normally suggests something is badly wrong. When you say you're using ssh as an authentication method, do you mean you're using ssh as a transport? Can you use ssh to login from your client to the server OK otherwise? $ export | grep -i CVS declare -x CVSROOT=:ext:my.server:/var/lib/cvs declare -x CVS_RSH=ssh And yes, ssh to the server works ok. Just a moment ago I tried a cvs up with another repository and it updated 1 file from the cvs server and then died with SIGBUS. Also, lock files that are left in the repository suggest that cvs was executed in the server, but ended with signal 10. -- - Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática| '@' || 'unl.edu.ar'; Universidad Nacional| DBA, Programador, del Litoral | Administrador -
Bug#402745: cvs Terminated with fatal signal 10
On Tue, Dec 12, 2006 at 09:43:19AM -0300, Martin Marques wrote: Package: cvs Version: 1:1.12.13-5 Severity: normal I have CVS configured to work with ssh as an external autentication mecanism. I just passed cvs from stable (sarge) to testing and I'm getting this error. When I try to update a repository remotly I get this: $ cvs -q up ? SISTEMA.csv ? javascript/prueba.html ? javascript/windowCargo.js Terminated with fatal signal 10 I the cvs tree (/var/lib/cvs/planta) I can find lock files related to the update I just executed: #cvs.rfl.bugs.16487 but with no proceses with id 16487. If I downgrade to stable (sarge) cvs works ok, but in testing I get these errors constantly. The repository in question is not been used by anybdy else. I'm the only one accessing it. Now, if I try to execute the same line on the local server, but still using ssh as the external autentication method, it works ok, even without removing the lock files that in the cvs directory. Hmmm. Signal 10 is SIGBUS, which normally suggests something is badly wrong. When you say you're using ssh as an authentication method, do you mean you're using ssh as a transport? Can you use ssh to login from your client to the server OK otherwise? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site... -- Simon Booth signature.asc Description: Digital signature
Bug#402745: cvs Terminated with fatal signal 10
On Tue, Dec 12, 2006 at 12:09:16PM -0300, Martin Marques wrote: On Tue, 12 Dec 2006 14:55:41 +, Steve McIntyre [EMAIL PROTECTED] wrote: On Tue, Dec 12, 2006 at 09:43:19AM -0300, Martin Marques wrote: Hmmm. Signal 10 is SIGBUS, which normally suggests something is badly wrong. When you say you're using ssh as an authentication method, do you mean you're using ssh as a transport? Can you use ssh to login from your client to the server OK otherwise? $ export | grep -i CVS declare -x CVSROOT=:ext:my.server:/var/lib/cvs declare -x CVS_RSH=ssh And yes, ssh to the server works ok. Just a moment ago I tried a cvs up with another repository and it updated 1 file from the cvs server and then died with SIGBUS. Also, lock files that are left in the repository suggest that cvs was executed in the server, but ended with signal 10. OK. Next question - is it cvs on your local machine or on the server that's dying? Can you provoke your client copy of cvs to dump core using ulimit -c unlimited? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402745: cvs Terminated with fatal signal 10
On Tue, 12 Dec 2006 15:27:42 +, Steve McIntyre [EMAIL PROTECTED] wrote: On Tue, Dec 12, 2006 at 12:09:16PM -0300, Martin Marques wrote: OK. Next question - is it cvs on your local machine or on the server that's dying? Can you provoke your client copy of cvs to dump core using ulimit -c unlimited? I think it's dying in the server, as it doesn't clean up lock files. Is there a way to know for sure where it's dying? Couldn't get core dumps. Sorry. BTW, the client machine has an older version 1.11.x of CVS. -- - Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática| '@' || 'unl.edu.ar'; Universidad Nacional| DBA, Programador, del Litoral | Administrador -
Bug#402745: cvs Terminated with fatal signal 10
On Tue, Dec 12, 2006 at 01:13:29PM -0300, Martin Marques wrote: On Tue, 12 Dec 2006 15:27:42 +, Steve McIntyre [EMAIL PROTECTED] wrote: On Tue, Dec 12, 2006 at 12:09:16PM -0300, Martin Marques wrote: OK. Next question - is it cvs on your local machine or on the server that's dying? Can you provoke your client copy of cvs to dump core using ulimit -c unlimited? I think it's dying in the server, as it doesn't clean up lock files. Is there a way to know for sure where it's dying? Check for errors on the server end as well. Couldn't get core dumps. Sorry. BTW, the client machine has an older version 1.11.x of CVS. Ah, OK. I wasn;t sure which end was which from your original mail. On the server, try setting CVS_PSERV_LIMIT_CORE=unlimited in /etc/cvs-pserver.conf, assuming that's a Debian machine. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Who needs computer imagery when you've got Brian Blessed? signature.asc Description: Digital signature
Bug#402745: cvs Terminated with fatal signal 10
On Tue, 12 Dec 2006 16:19:48 +, Steve McIntyre [EMAIL PROTECTED] wrote: On Tue, Dec 12, 2006 at 01:13:29PM -0300, Martin Marques wrote: On Tue, 12 Dec 2006 15:27:42 +, Steve McIntyre [EMAIL PROTECTED] wrote: Check for errors on the server end as well. What should I look for on the server? I didn't see anything strange so long (ssh authentication went ok, and no errors in messages or kern.log) BTW, the client machine has an older version 1.11.x of CVS. Ah, OK. I wasn;t sure which end was which from your original mail. On the server, try setting CVS_PSERV_LIMIT_CORE=unlimited in /etc/cvs-pserver.conf, assuming that's a Debian machine. But I'm not using pserver. I'm using ssh. Is it the same? The server is on Debian (where I reported the bug). The client is another Linux distribution with version 1.11.x of cvs. -- - Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática| '@' || 'unl.edu.ar'; Universidad Nacional| DBA, Programador, del Litoral | Administrador -
Bug#402745: cvs Terminated with fatal signal 10
On Tue, Dec 12, 2006 at 02:48:23PM -0300, Martin Marques wrote: On Tue, 12 Dec 2006 16:19:48 +, Steve McIntyre [EMAIL PROTECTED] wrote: On Tue, Dec 12, 2006 at 01:13:29PM -0300, Martin Marques wrote: On Tue, 12 Dec 2006 15:27:42 +, Steve McIntyre [EMAIL PROTECTED] wrote: Check for errors on the server end as well. What should I look for on the server? I didn't see anything strange so long (ssh authentication went ok, and no errors in messages or kern.log) BTW, the client machine has an older version 1.11.x of CVS. Ah, OK. I wasn;t sure which end was which from your original mail. On the server, try setting CVS_PSERV_LIMIT_CORE=unlimited in /etc/cvs-pserver.conf, assuming that's a Debian machine. But I'm not using pserver. I'm using ssh. Is it the same? Gah, yes. Sorry - silly mistake on my part. The server is on Debian (where I reported the bug). The client is another Linux distribution with version 1.11.x of cvs. In that case, I'd use a shell script wrapper on the server - install it as /usr/bin/cvs, and move the original cvs to cvs.real. The following should work for you as a wrapper, I hope: = #!/bin/sh cd /tmp ulimit -c unlimited cvs.real $@ = It should leave a core dump in /tmp for you; obviously, cd to some other directory if you prefer... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Because heaters aren't purple! -- Catherine Pitt signature.asc Description: Digital signature
Bug#402745: cvs Terminated with fatal signal 10
On Tue, 12 Dec 2006 18:00:08 +, Steve McIntyre [EMAIL PROTECTED] wrote: In that case, I'd use a shell script wrapper on the server - install it as /usr/bin/cvs, and move the original cvs to cvs.real. The following should work for you as a wrapper, I hope: = #!/bin/sh cd /tmp ulimit -c unlimited cvs.real $@ = It should leave a core dump in /tmp for you; obviously, cd to some other directory if you prefer... Here's the gdb output: bugs:/tmp# gdb /usr/bin/cvs.real GNU gdb 6.4.90-debian Copyright (C) 2006 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 sparc-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. (gdb) core /tmp/cvs-serv23795/src/prestamos/include/core Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libpam.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libdl.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Core was generated by `cvs.real server'. Program terminated with signal 10, Bus error. #0 0x00081e00 in error () -- - Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática| '@' || 'unl.edu.ar'; Universidad Nacional| DBA, Programador, del Litoral | Administrador -
Bug#402745: cvs Terminated with fatal signal 10
Hi Martin, Can you please try doing the same debugging trick after installing the cvs package from http://www.wooyd.org/debian/cvs It contains the non-stripped cvs binary. And type 'backtrace' or 'bt' at the gdb prompt after it loads up the core file, and attach the output to the bug. Thanks, -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
