[SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

grizzancs · 2009-07-28 21:27:00

Hi!

I've been trying to get everything OK on my desktop computer (which is pretty old - AthlonXP 2400+ (which can run on ~1.83 Ghz instead of 2Ghz , otherwise does not start)), but I've been experiencing problems with various packages)

The first core was with awesome, in libev - SIGILL, illegal instruction, which I could solve by recompiling libev with ABS (I changed nothing, just compile-install).

Now I was trying to use mount.cifs from samba, which gave a simple SEGSEGV, segmentation fault in glibc (/lib/ld-linux.so.2) , the recompile trick did not work this time.

But I don't really think there are so many strange errors in the newest, updated arch, and I did not experience anything like this.

glibc 2.10.1-3
libev 3.60-1

And these are the newest ones.

Am I missing the point somewhere, I am just simply unlucky and this is just a coincidence, or i may have some hardware issues? (memtest gave no error, however I did not run a full test). The SIGILL is interesting as well, how could a simple recompile fix that, the package should be OK in the repo, as that version is there for a long time)

I have tried to switch mirrors, reinstall every installed package, but did not help (made my libev go bad again).

Any ideas?

Last edited by grizzancs (2009-07-31 07:21:52)

djszapi · 2009-07-29 20:22:27

Welcome to the forum, gizzancs!

1. "which can run on ~1.83 Ghz instead of 2Ghz , otherwise does not start" -> How do you mean that?

Not so old machine, at the company there are older pc-s )

2. "Now I was trying to use mount.cifs from samba," -> Can you show the exact command you use ?

3. What's the different between two environment? Are they really the same, but hardware ?

4. You can debug with gdb/backtrace where the sigill/segfault occur. Btw. Can you the sigill/segfault related ouputs? I don't think the output is just this: "Sigkill" or "Segfault"

djgera · 2009-07-29 20:38:21

/usr/lib/libev.so.3.0.0 is compiled with SSE2 instructions. Your CPU can't understand this.

I filled a bug report for you http://bugs.archlinux.org/task/15724

djszapi · 2009-07-29 20:39:21

So you can build your hardware related support if it exist in an AUR package

djgera · 2009-07-30 18:33:23

Now is fixed

The following task is now closed:
FS#15724 - [libev] i686 pkg is compiled with SSE2 instructions.
User who did this - Chris Brannon (cmb)
Reason for closing: Fixed
Additional comments about closing: I rebuilt the package, since BaSh is inactive.

Check...

$ objdump -d usr/lib/libev.so.3.0.0 | grep xmm
$

Looks good! Thanks Chris

PS: Please mark as [SOLVED]

grizzancs · 2009-07-30 19:40:38

djgera wrote:

Now is fixed
(...)
PS: Please mark as [SOLVED]

Thank you very much for the bug report! This was (SSE2) something which I would never thought when I saw the SIGILL, but now I'll know, thanks for the tip as well.

I will not mark this as fixed yet, as the other problem still exists, I don't think making a new thread for that is a good idea.

djszapi wrote:

1. "which can run on ~1.83 Ghz instead of 2Ghz , otherwise does not start" -> How do you mean that?

The computer simply does not start, I have to manually reset the bios by putting the jumper to the 'reset' position (but usually it discovers that the 'new settings' are bad, and resets to 'safe' values (some very low frequency).

But I no longer think this is a hardware issue (at least I don't think something went wrong with mine, it still could be a platform issue like the previous).

djszapi wrote:

2. "Now I was trying to use mount.cifs from samba," -> Can you show the exact command you use ?

Yes, mount.cifs, without any parameters.

djszapi wrote:

3. What's the different between two environment? Are they really the same, but hardware ?

My notebook is Pentium-M, and the previous error was not present on it (it knows SSE2, that is understandable), however I did not try mount.cifs until this point on that. Now (for my surprise) it does crash on it as well - now this doesn't seem to be mystical in any way

I did not post backtrace in the first post, because the one I had was useless (most of it was stripped off by the compiler), and I did not found how to make a 'debug' package, after that I had given up thinking there is no common way to do it, and it would be different for each package. But shortly after the post I discovered http://wiki.archlinux.org/index.php/Deb … ing_Traces by accident, google did not find it (a bad name for such an important thing imho, I searched for 'making/creating debug package arch linux, etc').

I recompiled smbclient (the package mount.cifs belongs to) and glibc with the specified methods ( options=(!strip) and in build(): export CFLAGS/CXXFLAGS="$CFLAGS/$CXXFLAGS -g" ) ), checked the dates of the files (the lib and the executable have the current date), but trying to get a backtrace is still full of ??s, to be exact:

[grizzly@evilshade ~]$ ls -l /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 12 2009-07-30 19:59 /lib/ld-linux.so.2 -> ld-2.10.1.so
[grizzly@evilshade ~]$ ls -l /lib/ld-2.10.1.so 
-rwxr-xr-x 1 root root 224008 2009-07-30 19:59 /lib/ld-2.10.1.so
[grizzly@evilshade ~]$ ls -l /sbin/mount.cifs
-rwxr-xr-x 1 root root 36221 2009-07-30 21:23 /sbin/mount.cifs

[grizzly@evilshade ~]$ gdb mount.cifs
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)
(gdb) run
Starting program: /sbin/mount.cifs 

Program received signal SIGSEGV, Segmentation fault.
0xb7fb9456 in ?? ()
(gdb) bt
#0  0xb7fb9456 in ?? ()
#1  0xbfe39542 in ?? ()
#2  0xb7fb5818 in ?? ()
#3  0xbfe3956c in ?? ()
#4  0xb7fa15b9 in _dl_lookup_symbol_x () from /lib/ld-linux.so.2
#5  0xb7e48a36 in ?? ()
#6  0x00000001 in ?? ()
#7  0xbfe397f4 in ?? ()
#8  0xbfe397fc in ?? ()
#9  0xb7f8a2a0 in ?? ()
#10 0xbfe39790 in ?? ()
#11 0xffffffff in ?? ()
#12 0xb7fb4fc4 in ?? () from /lib/ld-linux.so.2
#13 0xb7fb6cf6 in ?? ()
#14 0x00000001 in ?? ()
#15 0xbfe397b0 in ?? ()
#16 0xb7fa58d6 in _dl_fixup (l=<value optimized out>, reloc_arg=<value optimized out>)
    at dl-runtime.c:114
#17 0xb7fb7721 in ?? ()
(gdb)

Now I know this is not a hardware issue, but a bug in smbclient, the only thing I am interested now is - why is this backtrace still so non-informative? I wish to debug/fix myself if I can, but I (and others as well) cannot do anything with this backtrace.

djszapi · 2009-07-30 19:43:54

#10 0xbfe39790 in ?? () -> it occurs generally when you built it without debug information, e.g. with stripped option.

grizzancs · 2009-07-30 19:48:11

seems double check was not enough - at third check (which was now) I realized, that there was a second "options=(xx)" in smbclient's PKGBUILD, which were probably overriding mine.

I will recompiile it with that, and let's see what happens. sorry

grizzancs · 2009-07-30 20:15:51

That did not helped - and leaving !strip as the only option did not help either

Last edited by grizzancs (2009-07-30 20:16:03)

djgera · 2009-07-31 06:02:05

You are welcome

About mount.cifs: Is not intented to use directly, should use via mount -t cifs. Because mount.cifs is not an executable, is a shared object (in other words a library) Executing a library result -> segmentation fault, (if not contains a stub, like libc)

About debug with gdb, is "an art" Many times not only needs rebuild the application, but also need all libraries used by it.
The flag -g can help, but is better -ggdb if you will plan in doing a real debug with gdb. In some cases this is not sufficient, also needs -gstabs+, that add much more information, like for example, if gcc "optimizes out" a value in a register, this information will not be available to debugger, but work with -gstabs+.
In a more deep level, -On should be removed or maybe adding -fno-inline-functions, (for example if a function is optimized in by gcc as "inlined) you can't see in gdb.

(sorry my english if you don't understand me)

grizzancs · 2009-07-31 07:21:21

djgera wrote:

About mount.cifs: Is not intented to use directly, should use via mount -t cifs. Because mount.cifs is not an executable, is a shared object (in other words a library) Executing a library result -> segmentation fault, (if not contains a stub, like libc)

Hm, I don't think that is a library - it's located in /sbin/, and if I type any parameters, it shows its help (also, at it's man page: http://www.samba.org/samba/docs/man/man … ifs.8.html it is written, that it is used commonly indirectly via mount).

But I thank for the tips about gdb - if I'll encounter some other error, it will definiately help me, and I think there are still lots of documentation about these tools (gdb) which needs to be read

I change this to fixed now.

djgera · 2009-07-31 14:49:02

grizzancs wrote:

djgera wrote:
About mount.cifs: Is not intented to use directly, should use via mount -t cifs. Because mount.cifs is not an executable, is a shared object (in other words a library) Executing a library result -> segmentation fault, (if not contains a stub, like libc)
Hm, I don't think that is a library - it's located in /sbin/, and if I type any parameters, it shows its help (also, at it's man page: http://www.samba.org/samba/docs/man/man … ifs.8.html it is written, that it is used commonly indirectly via mount).
But I thank for the tips about gdb - if I'll encounter some other error, it will definiately help me, and I think there are still lots of documentation about these tools (gdb) which needs to be read
I change this to fixed now.

No problem.

The location is irrelevant in this case.

$ readelf -h /sbin/mount.cifs | grep Type
  Type:                              DYN (Shared object file)

When you load the mount.cifs in gdb you can see that is load at adress 0x0000nnnn instead of 0x0804nnnn like a normal executable.

Arch Linux

#1 2009-07-28 21:27:00

[SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#2 2009-07-29 20:22:27

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#3 2009-07-29 20:38:21

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#4 2009-07-29 20:39:21

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#5 2009-07-30 18:33:23

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#6 2009-07-30 19:40:38

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#7 2009-07-30 19:43:54

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#8 2009-07-30 19:48:11

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#9 2009-07-30 20:15:51

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#10 2009-07-31 06:02:05

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#11 2009-07-31 07:21:21

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

#12 2009-07-31 14:49:02

Re: [SOLVED] strange cores (libev; mount.cifs in ld-linux.so (glibc))

Board footer