/ Forside / Teknologi / Operativsystemer / Linux / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Linux
#NavnPoint
o.v.n. 11177
peque 7911
dk 4814
e.c 2359
Uranus 1334
emesen 1334
stone47 1307
linuxrules 1214
Octon 1100
10  BjarneD 875
Linked libraries
Fra : Kenneth Brun Nielsen


Dato : 27-10-08 03:20

Jeg har to (næsten) identiske servere, hvor den ene nu volder
problemer efter noget opdatering.

Det drejer sig om en (binær) executable, som giver en segmentation
fault. Til orientering har det virket tidligere.

Hvis jeg kører en ldd på scriptet, på hver af maskinerne A (virker) og
B (segmentation fault), så er outputtet:

A (funktionel):
$ ldd <path to executable>
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40027000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
(0x4003c000)
libm.so.6 => /lib/i686/libm.so.6 (0x4007e000)
libc.so.6 => /lib/i686/libc.so.6 (0x400a1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

B (ufunktionel):
ldd <path to executable>
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x008ea000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
(0x00417000)
libm.so.6 => /lib/tls/libm.so.6 (0x007e4000)
libc.so.6 => /lib/tls/libc.so.6 (0x006ad000)
/lib/ld-linux.so.2 (0x00693000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0095a000)

Forskellene i de absolutte stier bekymrer mig ikke så meget (det
skyldes nok at installationerne ikke er helt identiske: RH72 vs
RHEL4). Men at der er en sti mere på maskine B har sandsynligvis
indflydelse på fejlen (jeg har nemlig haft pillet i netop libgcc_s.so.
1, som gav problemer andetsteds).

Kort sagt: hvordan f***** kan jeg fikse det? (jeg er ret grøn på dette
punkt, men bare spørg løs, hvis jeg har glemt noget væsentligt).

/Kenneth

 
 
Mogens Kjaer (27-10-2008)
Kommentar
Fra : Mogens Kjaer


Dato : 27-10-08 10:39

Kenneth Brun Nielsen wrote:
....
> Kort sagt: hvordan f***** kan jeg fikse det? (jeg er ret grøn på dette
> punkt, men bare spørg løs, hvis jeg har glemt noget væsentligt).

Man kunne forestille sig at det ikke er din executable,
men et af de øvrige libraries på B maskinen, som også kræver
libgcc_s.so.1, derfor er der én mere. Du kan jo prøve med ldd
på hver af de øvrige libs på B maskinen.

Jeg ville nok opgradere RH72 (reinstallere) til RHEL4 så maskinerne
er ens...

Mogens

--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Mobile: +45 22 12 53 25
Email: mk@crc.dk Homepage: http://www.crc.dk

Kenneth Brun Nielsen (27-10-2008)
Kommentar
Fra : Kenneth Brun Nielsen


Dato : 27-10-08 22:31


"Mogens Kjaer" <mk@crc.dk> skrev i en meddelelse
news:49058C39.50609@crc.dk...
> Kenneth Brun Nielsen wrote:
> ...
>> Kort sagt: hvordan f***** kan jeg fikse det? (jeg er ret grøn på dette
>> punkt, men bare spørg løs, hvis jeg har glemt noget væsentligt).
>
> Man kunne forestille sig at det ikke er din executable,
> men et af de øvrige libraries på B maskinen, som også kræver
> libgcc_s.so.1, derfor er der én mere. Du kan jo prøve med ldd
> på hver af de øvrige libs på B maskinen.

Du har ret. Et af de øvrige biblioteker linker til libgcc_s.so.1. Så det at
lib'et figurer i den ene liste, udgør nok ikke fejlen alene. Har du andre
forslag til, hvad der kan være ændret siden det har virket? Og ikke mindst
hvordan kommer jeg tilbage til den tilstand?

> Jeg ville nok opgradere RH72 (reinstallere) til RHEL4 så maskinerne
> er ens...

Det er ikke en mulighed i skrivende stund pga. ønsket bagudkombatibilitet
med tidligere arbejde (og det er iøvrigt RHEL4-maskinen, der volder
problemer).

Tak for svaret.

/Kenneth



Mogens Kjaer (28-10-2008)
Kommentar
Fra : Mogens Kjaer


Dato : 28-10-08 08:06

Kenneth Brun Nielsen wrote:
....
> Du har ret. Et af de øvrige biblioteker linker til libgcc_s.so.1. Så det at
> lib'et figurer i den ene liste, udgør nok ikke fejlen alene. Har du andre
> forslag til, hvad der kan være ændret siden det har virket? Og ikke mindst
> hvordan kommer jeg tilbage til den tilstand?

Hvorfor pillede du ved libgcc_s.so.1 i første omgang?

Kan du ikke lægge den rigtige tilbage?

Hvis et andet program kræver en speciel udgave af libgcc_s.so.1 kan
du jo lægge libgcc_s.so.1 i en speciel folder og sætte
LD_LIBRARY_PATH op til denne folder inden du starter dette program.

Mogens

--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Mobile: +45 22 12 53 25
Email: mk@crc.dk Homepage: http://www.crc.dk

Kenneth Brun Nielsen (28-10-2008)
Kommentar
Fra : Kenneth Brun Nielsen


Dato : 28-10-08 15:10

Mogens Kjaer <mk@crc.dk> wrote in news:4906B9D7.5010602@crc.dk:

> Kenneth Brun Nielsen wrote:
> ...
>> Du har ret. Et af de øvrige biblioteker linker til libgcc_s.so.1. Så
>> det at lib'et figurer i den ene liste, udgør nok ikke fejlen alene.
>> Har du andre forslag til, hvad der kan være ændret siden det har
>> virket? Og ikke mindst hvordan kommer jeg tilbage til den tilstand?
>
> Hvorfor pillede du ved libgcc_s.so.1 i første omgang?
>
> Kan du ikke lægge den rigtige tilbage?
>
> Hvis et andet program kræver en speciel udgave af libgcc_s.so.1 kan
> du jo lægge libgcc_s.so.1 i en speciel folder og sætte
> LD_LIBRARY_PATH op til denne folder inden du starter dette program.

Jeg pillede indledningsvist fordi et program netop satte LD_LIBRARY_PATH
op. Denne path pegede på en lib-path, der (bl.a) indeholdt en
libgcc_s.so.1, som gav nogle "glibc"-versionsfejl, når jeg efterfølgende
skrev selv simple kommandoer (naturligvis kommandoer, som brugte
libgcc_s.so.1).

Mit fix var gøre $LD_LIBRARY_PATH/libgcc_s.so.1 til et symbolsk link, som
pegede på en brugbar version af samme lib (/lib/libgcc_s.so.1). Det
virkede perfekt i alle henseender - altså lige indtil efter weekenden,
hvor det gav segmentation fault.

Jeg har efterfølgende fjernet det symbolske link og genindsat den
oprindelige fil, men det giver alligevel en segmentation fault. Af den
årsag gik jeg ud fra at der var noget permanent ændret et-eller-andet
sted som følge af det (midlertidige) symbolske link. Denne formodning
bunder muligvis/sandsynligvis i min egen uvidenhed (?).

Er der evt. nogle ændringer af denne slags, som først effektueres når man
boot'er maskinen? Det vil kunne forklare, at det hele virkede fredag, men
gav segmentation fault mandag.

Den fejlagtige maskine er, til orientering, en nyinstalleret RHEL4, som
_muligvis_ har fået opdateret nogle filer i løbet af fredagen. Måske er
disse ændringer først trådt i kraft efter reboot? (jeg forventer ikke
svar på alle disse hypoteser, men det kunne jo være at der sad en derude,
som fik gode ideér).

/Kenneth (med ny news-reader, idet der er laaang forsinkelse på Google
Groups pt.)

Mogens Kjaer (28-10-2008)
Kommentar
Fra : Mogens Kjaer


Dato : 28-10-08 15:21

Kenneth Brun Nielsen wrote:
....
> Jeg pillede indledningsvist fordi et program netop satte LD_LIBRARY_PATH
> op. Denne path pegede på en lib-path, der (bl.a) indeholdt en
> libgcc_s.so.1, som gav nogle "glibc"-versionsfejl, når jeg efterfølgende
> skrev selv simple kommandoer (naturligvis kommandoer, som brugte
> libgcc_s.so.1).

LD_LIBRARY_PATH bør ikke sættes op globalt; der bør så være
et wrapperscript for dette program som sætter LD_LIBRARY_PATH
op specielt til dette.

Kan du se hvad der er installeret for nyligt i /var/log/up2date* filerne?

Mogens

PS: Undlad at CC'e postings.

--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Mobile: +45 22 12 53 25
Email: mk@crc.dk Homepage: http://www.crc.dk

Søg
Reklame
Statistik
Spørgsmål : 177547
Tips : 31968
Nyheder : 719565
Indlæg : 6408797
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste