---

Efter jeg har opgraderet til FC3, er min SMACX (Alpha Centauri) holdt
op med at virke. Den eneste morskab jeg har tilbage her i livet er:

$smacpack

BUG! (Segmentation Fault) Going down hard...
Sid Meier's Planetary Pack 6.0a
Built with glibc-2.1 on x86
Stack dump:
{

...


Og eftersom lokigames jo er væk, hjælper det nok ikke at skrive til
deres support. Så jeg bliver vel nødt til at finde noget andet at
foretage mig, men jeg vil lige høre om der er andre der har haft et
tilsvarende problem, og ved hvad man kan gøre ved det.

--
/Wegge
Min holdning til Usenet - <http://wiki.wegge.dk/Usenet>
Min weblog - <http://blog.wegge.dk/>

---

Den 04 Apr 2005 21:17:55 +0200 skrev Anders Wegge Jakobsen:
> Efter jeg har opgraderet til FC3, er min SMACX (Alpha Centauri) holdt
> op med at virke. Den eneste morskab jeg har tilbage her i livet er:
>
> $smacpack
>
> BUG! (Segmentation Fault) Going down hard...
> Sid Meier's Planetary Pack 6.0a
> Built with glibc-2.1 on x86
> Stack dump:
> {
>
> ...
>
>
> Og eftersom lokigames jo er væk, hjælper det nok ikke at skrive til
> deres support. Så jeg bliver vel nødt til at finde noget andet at
> foretage mig, men jeg vil lige høre om der er andre der har haft et
> tilsvarende problem, og ved hvad man kan gøre ved det.

Prøv at køre smac.dynamic eller smacx.dynamic, de bruger systemets
libraries, hvor de andre er statisk linkede med oldgamle versioner
af fx SDL.

Jeg kan nu ikke se nogen grund til at opgraderingen skulle give
problemer, med statiske linkede programmer er der kun kernen eller
X-serveren tilbage, og min virker fint med 2.6.11.6 og 6.8.2.

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

---

"Kent" == Kent Friis <nospam@nospam.invalid> writes:

> Den 04 Apr 2005 21:17:55 +0200 skrev Anders Wegge Jakobsen:
>> Efter jeg har opgraderet til FC3, er min SMACX (Alpha Centauri) holdt
>> op med at virke. Den eneste morskab jeg har tilbage her i livet er:
>>
>> $smacpack
>>
>> BUG! (Segmentation Fault) Going down hard...
>> Sid Meier's Planetary Pack 6.0a
>> Built with glibc-2.1 on x86
>> Stack dump:
>> {
>>
>> ...
>>
>>
>> Og eftersom lokigames jo er væk, hjælper det nok ikke at skrive til
>> deres support. Så jeg bliver vel nødt til at finde noget andet at
>> foretage mig, men jeg vil lige høre om der er andre der har haft et
>> tilsvarende problem, og ved hvad man kan gøre ved det.

> Prøv at køre smac.dynamic eller smacx.dynamic, de bruger systemets
> libraries, hvor de andre er statisk linkede med oldgamle versioner
> af fx SDL.

Jeg får nøjagtig det samme resultat med .dynamic versionerne

> Jeg kan nu ikke se nogen grund til at opgraderingen skulle give
> problemer, med statiske linkede programmer er der kun kernen eller
> X-serveren tilbage, og min virker fint med 2.6.11.6 og 6.8.2.

Jeg sidder selv med 2.6.9-1 og 6.8.1, så jeg vil lige prøve at se om
det giver nogen forskel. Men jeg er mere nervøs for at der skulle have
sneget sig en ændret kernel-setting med et sted.

--
/Wegge
Min holdning til Usenet - <http://wiki.wegge.dk/Usenet>
Min weblog - <http://blog.wegge.dk/>

---

Kent Friis wrote:
>
> med statiske linkede programmer er der kun kernen eller
> X-serveren tilbage, og min virker fint med 2.6.11.6 og 6.8.2.

Selv hvis man beder linkeren om at linke statisk vil der
stadig være lidt af koden, der bliver linket dynamisk.
Det gælder f.eks. kode til opslag af hostnavne.

Jeg ville prøve at køre koden i et chroot med den gamle
udgave af alle libraries. I så fald bliver det nok lidt
tricky at få kontakt til X serveren. Man kan naturligvis
køre over TCP, det er dog ikke slået til som default i
Fedora Core. Og selv efter man har slået det til er det
nok stadig tricky at få accelereret grafik til at virke
fra et chroot.

--
Kasper Dupont

---

"Kasper" == Kasper Dupont <kasperd@daimi.au.dk> writes:

> Kent Friis wrote:
>>
>> med statiske linkede programmer er der kun kernen eller
>> X-serveren tilbage, og min virker fint med 2.6.11.6 og 6.8.2.

> Selv hvis man beder linkeren om at linke statisk vil der
> stadig være lidt af koden, der bliver linket dynamisk.
> Det gælder f.eks. kode til opslag af hostnavne.

> Jeg ville prøve at køre koden i et chroot med den gamle
> udgave af alle libraries. I så fald bliver det nok lidt
> tricky at få kontakt til X serveren. Man kan naturligvis
> køre over TCP, det er dog ikke slået til som default i
> Fedora Core. Og selv efter man har slået det til er det
> nok stadig tricky at få accelereret grafik til at virke
> fra et chroot.

Ville det så ikke være nemmere at bruge LD_PRELOAD=/lib/libfoo...

Eller er der andre sideeffgekter af et chroot?

--
/Wegge
Min holdning til Usenet - <http://wiki.wegge.dk/Usenet>
Min weblog - <http://blog.wegge.dk/>

---

Anders Wegge Jakobsen wrote:
>
> Ville det så ikke være nemmere at bruge LD_PRELOAD=/lib/libfoo...
>
> Eller er der andre sideeffgekter af et chroot?

Så vidt jeg husker virker LD_PRELOAD slet ikke på statisk
linkede executables. Pointen med chroot skulle være, at
uanset hvilke filer den åbner, så får den en udgave, der
matcher den library version programmet er linket mod.

--
Kasper Dupont

---

Den 05 Apr 2005 13:05:55 +0200 skrev Anders Wegge Jakobsen:
>"Kasper" == Kasper Dupont <kasperd@daimi.au.dk> writes:
>
>> Kent Friis wrote:
>>>
>>> med statiske linkede programmer er der kun kernen eller
>>> X-serveren tilbage, og min virker fint med 2.6.11.6 og 6.8.2.
>
>> Selv hvis man beder linkeren om at linke statisk vil der
>> stadig være lidt af koden, der bliver linket dynamisk.
>> Det gælder f.eks. kode til opslag af hostnavne.
>
>> Jeg ville prøve at køre koden i et chroot med den gamle
>> udgave af alle libraries. I så fald bliver det nok lidt
>> tricky at få kontakt til X serveren. Man kan naturligvis
>> køre over TCP, det er dog ikke slået til som default i
> > Fedora Core. Og selv efter man har slået det til er det
>> nok stadig tricky at få accelereret grafik til at virke
>> fra et chroot.
>
> Ville det så ikke være nemmere at bruge LD_PRELOAD=/lib/libfoo...

LD_LIBRARY_PATH ville nok være smartere.

> Eller er der andre sideeffgekter af et chroot?

Alt flyttes, hvad der så er relevant for spillet kommer an på hvilke
filer det læser.

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

---

Anders Wegge Jakobsen wrote:
>
> Efter jeg har opgraderet til FC3, er min SMACX (Alpha Centauri) holdt
> op med at virke. Den eneste morskab jeg har tilbage her i livet er:
>
> $smacpack
>
> BUG! (Segmentation Fault) Going down hard...
> Sid Meier's Planetary Pack 6.0a
> Built with glibc-2.1 on x86
> Stack dump:
> {

Det ser ud til at du har klippet nogle relevante oplysninger
væk. I øvrigt kan det sikkert også hjælpe med at finde årsagen
hvis man bruger strace.

--
Kasper Dupont

---

"Kasper" == Kasper Dupont <kasperd@daimi.au.dk> writes:

> Anders Wegge Jakobsen wrote:
>>
>> Efter jeg har opgraderet til FC3, er min SMACX (Alpha Centauri) holdt
>> op med at virke. Den eneste morskab jeg har tilbage her i livet er:
>>
>> $smacpack
>>
>> BUG! (Segmentation Fault) Going down hard...
>> Sid Meier's Planetary Pack 6.0a
>> Built with glibc-2.1 on x86
>> Stack dump:
>> {

> Det ser ud til at du har klippet nogle relevante oplysninger

Sikkert, men medmindre du sidder med koden, ved jeg ikke hvor meget
du kan få ud af:

[0x80d585d]
[0x420]
[0x813494e]
[0x8112094]
[0x8111f23]
[0x810be8d]
[0x810c00e]
[0x8103c0d]
[0x80fb629]
[0x80fb708]
[0x806b19b]
[0x80d21de]
[0x81a122d]
[0x8048111]

> væk. I øvrigt kan det sikkert også hjælpe med at finde årsagen
> hvis man bruger strace.

Det siger mig ikke så meget:

rt_sigaction(SIGINT, {0x810c620, [], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x810c620, [], SA_RESTART}, {SIG_DFL}, 8) = 0
brk(0x82e9000) = 0x82e9000
pipe([5, 6]) = 0
clone(child_stack=0x82e8358, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) = 23595
write(6, "\0\0\0\0\5\0\0\0HZ\354\366\0\0\0\0\0\0\0\0\226X \10\267"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
write(6, "\300\34#\10\0\0\0\0\0\366\377\376\24 \21\10\250b.\10\0"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
rt_sigsuspend([]--- SIGRTMIN (Unknown signal 32) @ 0 (0) ---
) = -1 EINTR (Interrupted system call)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---

--
/Wegge
Min holdning til Usenet - <http://wiki.wegge.dk/Usenet>
Min weblog - <http://blog.wegge.dk/>

---

Anders Wegge Jakobsen wrote:
>
> Sikkert, men medmindre du sidder med koden, ved jeg ikke hvor meget
> du kan få ud af:
>
> [0x80d585d]
[...]
> [0x8048111]

Det må jeg desværre give dig ret i. Det stack trace er
ikke til ret megen hjælp.

>
> > væk. I øvrigt kan det sikkert også hjælpe med at finde årsagen
> > hvis man bruger strace.
>
> Det siger mig ikke så meget:
>
> rt_sigaction(SIGINT, {0x810c620, [], SA_RESTART}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGTERM, {0x810c620, [], SA_RESTART}, {SIG_DFL}, 8) = 0
> brk(0x82e9000) = 0x82e9000
> pipe([5, 6]) = 0
> clone(child_stack=0x82e8358, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) = 23595
> write(6, "\0\0\0\0\5\0\0\0HZ\354\366\0\0\0\0\0\0\0\0\226X \10\267"..., 148) = 148
> rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
> write(6, "\300\34#\10\0\0\0\0\0\366\377\376\24 \21\10\250b.\10\0"..., 148) = 148
> rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
> rt_sigsuspend([]--- SIGRTMIN (Unknown signal 32) @ 0 (0) ---
> ) = -1 EINTR (Interrupted system call)
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---

Nej, det fortæller os ikke ret meget om hvad der går galt.
Ikke andet end at fejlen tilsyneladende opstår inde i en
signal handler. Jeg kan se, at den allerede har mindst to
tråde kørende på det tidspunkt hvor den går ned. Hvad vi
så kan bruge den oplysning til, udover at det bare bliver
mere compliceret at fejlfinde, ved jeg ikke.

Prøv evt. at bruge -f for at se oplysninger om alle tråde
og -o for at gemme output til en fil. Og kig så efter,
hvilke dynamiske libraries de to udgaver bruger.

--
Kasper Dupont