---

Hej gruppe.

Jeg har installeret en fedora core 5 server som skal bruges til at køre
et økonomisystem. Installationen af systemet står udviklingsfirmaet selv
for, men de er løbet ind i problemer.

De får en segmentation fault når de prøver at køre et program.

Jeg har også forsøgt, og end med at køre det med strace.

Jeg har ikke den store udvilkererfaring og kan ikke gennemskue hvad der
sker via strace outputtet.

Mon nogen herinde kan hjælpe?

Her er outputtet:

[root@server02 bin]# strace ./meramapout
execve("./meramapout", ["./meramapout"], [/* 18 vars */]) = 0
brk(0) = 0x8273000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x350000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=20958, ...}) = 0
mmap2(NULL, 20958, PROT_READ, MAP_PRIVATE, 3, 0) = 0x3b9000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0J\270\255"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1532536, ...}) = 0
mmap2(0xac6000, 1254780, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xac6000
mmap2(0xbf3000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12d) = 0xbf3000
mmap2(0xbf6000, 9596, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xbf6000
close(3) = 0
open("/lib/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`C\300\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=199700, ...}) = 0
mmap2(0xc01000, 147584, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xc01000
mmap2(0xc24000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22) = 0xc24000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x111000
set_thread_area({entry_number:-1 -> 6, base_addr:0x1116c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xc24000, 4096, PROT_READ) = 0
mprotect(0xbf3000, 8192, PROT_READ) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 5003 detached
[root@server02 bin]#


Håber i kan hjælpe.

/Kasper

---

On Mon, 2006-08-14 at 16:33 +0200, Kasper Nordal Lund wrote:
> De får en segmentation fault når de prøver at køre et program.

Hvis de selv har kildeteksten, kan gdb vise hvilken linie der skaber
problemmet.

> Jeg har også forsøgt, og end med at køre det med strace.

Kan du smide "-fF -o trace=file" som argumenter til strace?

> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x111000
> set_thread_area({entry_number:-1 -> 6, base_addr:0x1116c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> mprotect(0xc24000, 4096, PROT_READ) = 0
> mprotect(0xbf3000, 8192, PROT_READ) = 0

Jeg er lidt usikker på dette, resten så fint ud.

---

On Mon, 14 Aug 2006 16:33:10 +0200, Kasper Nordal Lund wrote:

>mprotect(0xbf3000, 8192, PROT_READ) = 0 --- SIGSEGV (Segmentation
>fault) @ 0 (0) --- +++ killed by SIGSEGV +++mprotect(0xc24000, 4096,
>PROT_READ)w> = 0 mprotect(0xbf3000, 8192, PROT_READ) = 0 --- SIGSEGV
>(Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++

Jeg tror, det er denne instruktion, der giver problemer:

DESCRIPTION
The function mprotect() specifies the desired protection for the
memory page(s) containing part or all of the interval
[addr,addr+len-1]. If an access is disallowed by the
protection given it, the program receives a SIGSEGV.

Det kunne tyde på overlappende memory segmenter. Du anvender ikke
programmet på en 64-bit arkitektur?

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

On Mon, 14 Aug 2006 17:56:21 +0200, Michael Rasmussen wrote:

>
> Jeg tror, det er denne instruktion, der giver problemer:
>
> DESCRIPTION
> The function mprotect() specifies the desired protection for the
> memory page(s) containing part or all of the interval
> [addr,addr+len-1]. If an access is disallowed by the
> protection given it, the program receives a SIGSEGV.
>
> Det kunne tyde på overlappende memory segmenter. Du anvender ikke
> programmet på en 64-bit arkitektur?

Jeg er ret sikker på det er en 32bit arkitetktur, hvordan kan jeg tjekke?

Det er under alle omstændigheder et 32 bit OS.

---

On Mon, 14 Aug 2006 18:13:17 +0200, Kasper Nordal Lund wrote:

>
> Jeg er ret sikker på det er en 32bit arkitetktur, hvordan kan jeg tjekke?
>
Har jeg faktisk ingen anelse om. Prøvede lige med dmesg på min Sempron -
64bit, men uden resultat.

Det virker i hvertfald på mig som om, at de laver lidt pointer
adressering til heap, og måske deres algoritme kun virker under 32-bit
adresserum - vil iøvrigt ikke være første gang, noget sådan sker

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

On Mon, 14 Aug 2006 18:46:41 +0200, Michael Rasmussen wrote:

> On Mon, 14 Aug 2006 18:13:17 +0200, Kasper Nordal Lund wrote:
>
>>
>> Jeg er ret sikker på det er en 32bit arkitetktur, hvordan kan jeg tjekke?
>>
> Har jeg faktisk ingen anelse om. Prøvede lige med dmesg på min Sempron -
> 64bit, men uden resultat.
>
> Det virker i hvertfald på mig som om, at de laver lidt pointer
> adressering til heap, og måske deres algoritme kun virker under 32-bit
> adresserum - vil iøvrigt ikke være første gang, noget sådan sker

cat /proc/cpuinfo giver heller intet jeg kan få noget ud af..

---

On Mon, 14 Aug 2006 18:51:32 +0200, Kasper Nordal Lund wrote:

>
> cat /proc/cpuinfo giver heller intet jeg kan få noget ud af..
Ifølge denne artikel, vil en 64bit cpu have et flag enabled ved navn lm
http://www.cyberciti.biz/nixcraft/vivek/blogger/2006/04/how-do-i-find-out-if-my-server-cpu-can.php

Det passer faktisk også hos mig:
P4-32bit
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Pentium(R) 4 CPU 1.70GHz
stepping : 2
cpu MHz : 425.000
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm up
bogomips : 3394.10

AMD32/64bit
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 44
model name : AMD Sempron(tm) Processor 3000+
stepping : 2
cpu MHz : 1800.000
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm ts fid vid ttp tm stc
bogomips : 3625.69

Hvis ovenstående holder, er det min teori, at i skal genoversætte
programmet på den computer, i vil anvende programmet.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

On Mon, 14 Aug 2006 19:15:39 +0200, Michael Rasmussen wrote:

>
> Hvis ovenstående holder, er det min teori, at i skal genoversætte
> programmet på den computer, i vil anvende programmet.
Fandt lige noget på kernel.org:
http://blog.gmane.org/gmane.linux.kernel/day=20060223
"The sys_mmap2() ABI is that the page shift is always fixed to whatever
page size is reasonable for the architecture, typically 2^12. The syscall
should never be exposed as mmap2(), only as the large file size version
of mmap() (aka mmap64()). The other consideration is that it should not
be implemented in 64 bit ABIs, as those machines should be using a 64 bit
native mmap(). Does that clear things up a bit? Cheers,"
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

On Mon, 14 Aug 2006 19:15:39 +0200, Michael Rasmussen wrote:

> Hvis ovenstående holder, er det min teori, at i skal genoversætte
> programmet på den computer, i vil anvende programmet.

Det ser ud til at det er en 64 bit CPU :(

Fanden tage 64 bit CPU'er ;)

Det fremgår ingen steder på det tilbud jeg har set at det skulle være
en 64 bit CPU - øv...

---

On Mon, 14 Aug 2006 23:01:11 +0200, Kasper Nordal Lund wrote:

>
> Det ser ud til at det er en 64 bit CPU :(
>
Nu ved jeg ikke, hvilken distro du benytter, men Gentoo og Suse skulle
vist være de bedste til en mikset miljø mellem 32 og 64 bit, så måske
du kunne undersøge det nærmere. Eventuelt den ny Novell Enterprise
version af Suse.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

>>>>> "KNL" == Kasper Nordal Lund <kasper@fakeusenet.dk> writes:

KNL> On Mon, 14 Aug 2006 19:15:39 +0200, Michael Rasmussen wrote:
>> Hvis ovenstående holder, er det min teori, at i skal genoversætte
>> programmet på den computer, i vil anvende programmet.

KNL> Det ser ud til at det er en 64 bit CPU :(

KNL> Fanden tage 64 bit CPU'er ;)

KNL> Det fremgår ingen steder på det tilbud jeg har set at det skulle
KNL> være en 64 bit CPU - øv...

Hvis du kører et 32-bit OS, så kan programmet ikke se, at det kører på
en 64-bit CPU. Med mindre det checker CPUID, naturligvis. (Men hvorfor
skulle nogen vælge bevidst at forhindre kørsel på 64-bit CPU'er?)


/Benny

---

On Mon, 14 Aug 2006 23:39:47 +0200, Benny Amorsen wrote:


> Hvis du kører et 32-bit OS, så kan programmet ikke se, at det kører på
> en 64-bit CPU. Med mindre det checker CPUID, naturligvis. (Men hvorfor
> skulle nogen vælge bevidst at forhindre kørsel på 64-bit CPU'er?)
>
Jeg tror heller ikke nogen bevidst, vil forhindre det, men hvis programmet
laver pointer aritmetik til heap, og programmet ikke oprindeligt har
været forudset, skulle afvikles under 64bit adresserum, kan det sagtens
give uheldige bivirkninger.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

>>>>> "MR" == Michael Rasmussen <mir@miras.org> writes:

MR> Jeg tror heller ikke nogen bevidst, vil forhindre det, men hvis
MR> programmet laver pointer aritmetik til heap, og programmet ikke
MR> oprindeligt har været forudset, skulle afvikles under 64bit
MR> adresserum, kan det sagtens give uheldige bivirkninger.

Hvis man kører et 32-bit OS på en x86_64-CPU, så er der kun 32 bit til
rådighed. Fuldstændig som hvis processoren ikke kunne køre i
64-bit-mode overhovedet.


/Benny

---

On 2006-08-15, Benny Amorsen <benny+usenet@amorsen.dk> wrote:
> Hvis man kører et 32-bit OS på en x86_64-CPU, så er der kun 32 bit til
> rådighed. Fuldstændig som hvis processoren ikke kunne køre i
> 64-bit-mode overh

Undskyld eventuelle maerkelige tegn, jeg er ikke hjemme og maa ty til
slrn.

En uname -a giver foelgende:

[kasper@server02 ~]$ uname -a
Linux server02 2.6.16-1.2133_FC5smp #1 SMP Tue Jun 6
01:52:09 EDT 2006 i686 i686 i386 GNU/Linux

Jeg kan ikke se ud fra det det skulle vaere et 64 bit os, men alligevel
virker det ikke.

---

On Tue, 15 Aug 2006 11:26:51 +0200, Kasper Lund wrote:

> [kasper@server02 ~]$ uname -a
> Linux server02 2.6.16-1.2133_FC5smp #1 SMP Tue Jun 6 01:52:09 EDT 2006
> i686 i686 i386 GNU/Linux
>
Kunne ovenstående ikke tyde på, at den kører i 64bit mode? smp anvendes
til multi-processor systemer, og da du ikke har nævnt dette, er det
sikkert en multikerne AMD processor, der sidder i maskinen. Disse leveres
kun i 64bit, hvorfor jeg er ret sikker på, at du kører degrade til 32bit
for os, men programmet vil, hvis det laver en undersøgelse for 32/64
bit, få den besked, at systemet er et 64bit
> Jeg kan ikke se ud fra det det skulle vaere et 64 bit os, men alligevel
> virker det ikke.
Der er ikke anden udvej end en genoversættelse fra kilden. Er det et
problem? Det er måske CSS?

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen <mir@miras.org> writes:

> On Tue, 15 Aug 2006 11:26:51 +0200, Kasper Lund wrote:
>
> > [kasper@server02 ~]$ uname -a
> > Linux server02 2.6.16-1.2133_FC5smp #1 SMP Tue Jun 6 01:52:09 EDT 2006
> > i686 i686 i386 GNU/Linux
> >
> Kunne ovenstående ikke tyde på, at den kører i 64bit mode?

Nej. 64 bit ser sådan her ud:

$ uname -a
Linux viggo 2.6.11.4-21.13-smp #1 SMP Mon Jul 17 09:21:59 UTC 2006
x86_64 x86_64 x86_64 GNU/Linux


> smp anvendes
> til multi-processor systemer, og da du ikke har nævnt dette, er det
> sikkert en multikerne AMD processor, der sidder i maskinen. Disse leveres
> kun i 64bit, hvorfor jeg er ret sikker på, at du kører degrade til 32bit
> for os, men programmet vil, hvis det laver en undersøgelse for 32/64
> bit, få den besked, at systemet er et 64bit
> > Jeg kan ikke se ud fra det det skulle vaere et 64 bit os, men alligevel
> > virker det ikke.
> Der er ikke anden udvej end en genoversættelse fra kilden. Er det et
> problem? Det er måske CSS?
>
> --
> Hilsen/Regards
> Michael Rasmussen
> http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
>

--
O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

On Tue, 15 Aug 2006 12:12:33 +0200, Michael Rasmussen wrote:

>>
> Kunne ovenstående ikke tyde på, at den kører i 64bit mode? smp anvendes
> til multi-processor systemer, og da du ikke har nævnt dette, er det
> sikkert en multikerne AMD processor, der sidder i maskinen. Disse leveres
> kun i 64bit, hvorfor jeg er ret sikker på, at du kører degrade til 32bit
> for os,

[kasper@server02 ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.20GHz
stepping : 3
cpu MHz : 3200.305
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr
bogomips : 6407.88

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.20GHz
stepping : 3
cpu MHz : 3200.305
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr
bogomips : 6400.34

---

On Tue, 15 Aug 2006 16:49:29 +0200, Kasper Nordal Lund wrote:

> [kasper@server02 ~]$ cat /proc/cpuinfo processor : 0
> vendor_id : GenuineIntel
> cpu family : 15
> model : 4
> model name : Intel(R) Pentium(R) 4 CPU 3.20GHz stepping : 3
> cpu MHz : 3200.305
> cache size : 2048 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 5
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
> constant_tsc pni monitor ds_cpl est cid cx16 xtpr bogomips :
> 6407.88
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 15
> model : 4
> model name : Intel(R) Pentium(R) 4 CPU 3.20GHz stepping : 3
> cpu MHz : 3200.305
> cache size : 2048 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 5
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
> constant_tsc pni monitor ds_cpl est cid cx16 xtpr bogomips :
> 6400.34
Okey. Det er altså en dual-core P4. Et hurtigt forslag: Prøv at boote
på en enkel-processor kerne - uden smp extention. Måske dit
program/eller OS ikke fungerer optimalt med en SMP-kerne.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Benny Amorsen skrev:
>>>>>> "MR" == Michael Rasmussen <mir@miras.org> writes:
>
> MR> Jeg tror heller ikke nogen bevidst, vil forhindre det, men hvis
> MR> programmet laver pointer aritmetik til heap, og programmet ikke
> MR> oprindeligt har været forudset, skulle afvikles under 64bit
> MR> adresserum, kan det sagtens give uheldige bivirkninger.
>
> Hvis man kører et 32-bit OS på en x86_64-CPU, så er der kun 32 bit til
> rådighed. Fuldstændig som hvis processoren ikke kunne køre i
> 64-bit-mode overhovedet.

Kan det ikke tænkes, at programmet er compileret til 64 bit eller tester
forkert (på CPU-niveau) og *tror*, det kører 64 bit? Hvis det er
tilfældet, kan der nemt komme nogle "vilde pointere" i anvendelse.

Under alle omstændigheder vil jeg mene, at det er udviklerne, som i
første omgang skal se på problemet.


Apropos:

Jeg har et SIGSEQV-problem med dd i 32-bit Ubuntu på en 64-bit CPU:

> per@pc4u/ddtest$ dd if=fejl of=fejl.dd
> 13+1 records in
> 13+1 records out
> Lagersegmentfejl

Hvis jeg bruger modulet dd fra Debian Sarge (sikkert 32-bit only), får
den også afslutningen korrekt med:

> per@pc4u/ddtest$ /media/USB/dd if=fejl of=fejl.dd
> 13+1 records in
> 13+1 records out
> 6788 bytes transferred in 0,000326 seconds (20819132 bytes/sec)

Denne fejl er til at leve med, men det kunne være et lignende problem,
Kasper oplever.

mvh Per

---

Per Riber <nospam@none.invalid> writes:

> > Lagersegmentfejl

Jeg har lige kørt dd på Ubuntu og set samme fejl - tak for at vise at
det er slutbeskeden der udløser fejlen.

Havde jeg god tid havde jeg undersøgt problemet :)
--
Thorbjørn Ravn Andersen

---

Thorbjørn Ravn Andersen skrev:
> Per Riber <nospam@none.invalid> writes:
>
>>> Lagersegmentfejl
>
> Jeg har lige kørt dd på Ubuntu og set samme fejl - tak for at vise at
> det er slutbeskeden der udløser fejlen.

Selv tak. Det kunne være et bufferoverløb under opbygning af "bundlinjen".

> Havde jeg god tid havde jeg undersøgt problemet :)

Ditto her, men jeg mangler både tid og evner, så den slags problemer
plejer så at sige "at løse sig selv" for mit vedkommende

Men hvis du eller andre hører om løsningen, kunne jeg godt tænke mig at
vide, om fejlen overhovedet har noget med 32/64-bit at gøre.

mvh Per

---

Thorbjørn Ravn Andersen skrev:
> Per Riber <nospam@none.invalid> writes:
>
>>> Lagersegmentfejl
>
> Jeg har lige kørt dd på Ubuntu og set samme fejl - tak for at vise at
> det er slutbeskeden der udløser fejlen.
>
> Havde jeg god tid havde jeg undersøgt problemet :)

PS: Der var den minsandten igen - og det er en "gammel fejl"

Se http://www.mail-archive.com/ubuntu-ru@lists.ubuntu.com/msg01082.html

Resultat:

per@pc4u/ddtest$ LANG=C dd if=fejl of=fejl.dd
13+1 records in
13+1 records out
6788 bytes (6.8 kB) copied, 0.000128 seconds, 53.0 MB/s

mvh Per

---

Per Riber <nospam@none.invalid> writes:

> Se http://www.mail-archive.com/ubuntu-ru@lists.ubuntu.com/msg01082.html

Mit russiske er ikke specielt godt (faktisk præcis så godt som
babelfisken) men udfra hvad du siger og kuren lader det til at være en
oversætterfejl, altså den streng der bruges til at lave den danske udgave.

Vil du fejlmelde det? Der er vist et link til formålet.

--
Thorbjørn Ravn Andersen

---

Thorbjørn Ravn Andersen skrev:

>> Se http://www.mail-archive.com/ubuntu-ru@lists.ubuntu.com/msg01082.html
>
> Mit russiske er ikke specielt godt (faktisk præcis så godt som
> babelfisken)

Ditto her, men det væsentlige var jo på engelsk... Deres løsningsforslag
går på at modificere coreutils.mo, men beskrivelsen indeholder lidt for
mange russiske bogstaver til at jeg kan få den til at virke.

> men udfra hvad du siger og kuren lader det til at være en
> oversætterfejl, altså den streng der bruges til at lave den danske udgave.

Også min første indskydelse, men det er lidt påfaldende, at der er fejl
i de danske, russiske og tyske oversættelser samtidig

> Vil du fejlmelde det? Der er vist et link til formålet.

Nej, jeg vil næppe gøre yderligere ud af det.

mvh Per

---

Den Tue, 15 Aug 2006 21:53:29 +0200 skrev Per Riber:
> Thorbjørn Ravn Andersen skrev:
>
>>> Se http://www.mail-archive.com/ubuntu-ru@lists.ubuntu.com/msg01082.html
>>
>> Mit russiske er ikke specielt godt (faktisk præcis så godt som
>> babelfisken)
>
> Ditto her, men det væsentlige var jo på engelsk... Deres løsningsforslag
> går på at modificere coreutils.mo, men beskrivelsen indeholder lidt for
> mange russiske bogstaver til at jeg kan få den til at virke.
>
>> men udfra hvad du siger og kuren lader det til at være en
>> oversætterfejl, altså den streng der bruges til at lave den danske udgave.
>
> Også min første indskydelse, men det er lidt påfaldende, at der er fejl
> i de danske, russiske og tyske oversættelser samtidig

Oversættelser ændrer vel kun teksten, og ikke koden? Så kan de da
ikke give segfaults, medmindre der er noget andet galt i koden.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

> Oversættelser ændrer vel kun teksten, og ikke koden? Så kan de da
> ikke give segfaults, medmindre der er noget andet galt i koden.

Hvis der prøves at proppe noget ind i en null-pointer, eller forsøges
at følge noget der ikke er en pointer som en pointer. Pointere er
nowet værre noget.
--
Thorbjørn Ravn Andersen

---

Den 15 Aug 2006 22:43:44 +0200 skrev Thorbjørn Ravn Andersen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> Oversættelser ændrer vel kun teksten, og ikke koden? Så kan de da
>> ikke give segfaults, medmindre der er noget andet galt i koden.
>
> Hvis der prøves at proppe noget ind i en null-pointer, eller forsøges
> at følge noget der ikke er en pointer som en pointer. Pointere er
> nowet værre noget.

Men *tekst* indeholder ikke pointere. Nu ved jeg ikke lige hvordan
oversættelsen af dd er lavet, derfor "?" - men hvis det er vha.
en tekst-fil der indeholder den danske oversættelse, kan oversættelsen
ikke give en fejl medmindre der er en fejl i koden.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

> Men *tekst* indeholder ikke pointere. Nu ved jeg ikke lige hvordan
> oversættelsen af dd er lavet, derfor "?" - men hvis det er vha.
> en tekst-fil der indeholder den danske oversættelse, kan oversættelsen
> ikke give en fejl medmindre der er en fejl i koden.

Hvis du bemærker den tekstlinie der skal laves, så skal der proppes
indtil flere værdier ind i den. Det er noget med %s, %x, og andre
væmmeligheder til sprintf... Flere af disse %-ting spiser pointere.

Altså, at oversættelsen som sådan er fejlbehæftet således at den
videre brug heraf går i gulvet, men at selve opslaget af oversættelsen
ikke er problematisk.

--
Thorbjørn Ravn Andersen

---

Den 15 Aug 2006 22:56:02 +0200 skrev Thorbjørn Ravn Andersen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> Men *tekst* indeholder ikke pointere. Nu ved jeg ikke lige hvordan
>> oversættelsen af dd er lavet, derfor "?" - men hvis det er vha.
>> en tekst-fil der indeholder den danske oversættelse, kan oversættelsen
>> ikke give en fejl medmindre der er en fejl i koden.
>
> Hvis du bemærker den tekstlinie der skal laves, så skal der proppes
> indtil flere værdier ind i den. Det er noget med %s, %x, og andre
> væmmeligheder til sprintf... Flere af disse %-ting spiser pointere.

For ikke ret længe siden hed den slags "format string vulnerability"


Ok, her er det så fra en fil og ikke noget der modtages over netværket,
men problemet er det samme. Og den dag fx sudo begynder at have den
slags oversættelser, og brugeren kan vælge hvilken fil oversættelsen
skal hentes fra, går det galt igen.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Thorbjørn Ravn Andersen skrev:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> Oversættelser ændrer vel kun teksten, og ikke koden? Så kan de da
>> ikke give segfaults, medmindre der er noget andet galt i koden.
>
> Hvis der prøves at proppe noget ind i en null-pointer, eller forsøges
> at følge noget der ikke er en pointer som en pointer. Pointere er
> nowet værre noget.

Sure, men de er jo helt uundværlige. Det gælder bare om at have styr på
deres indhold

mvh Per

---

On Tue, 15 Aug 2006 20:27:38 +0000, Kent Friis wrote:

>
> Oversættelser ændrer vel kun teksten, og ikke koden? Så kan de da ikke
> give segfaults, medmindre der er noget andet galt i koden.
>
Benyttes gnu-gettext har jeg før set fejloversættelser - grundet forkert
tegnkodning, har resulteret i at oversættelsesfunktionen har returneret
NULL. Dette vil stort set altid være resultatet, hvis indlæsning af
første tegn fejler, eller ID er udefineret i pot-filen.

#define _(String) dgettext (DOMAIN, String)

Hvor:
char * dgettext (const char * domainname, const char * msgid);

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Den Tue, 15 Aug 2006 22:52:53 +0200 skrev Michael Rasmussen:
> On Tue, 15 Aug 2006 20:27:38 +0000, Kent Friis wrote:
>
>>
>> Oversættelser ændrer vel kun teksten, og ikke koden? Så kan de da ikke
>> give segfaults, medmindre der er noget andet galt i koden.
>>
> Benyttes gnu-gettext har jeg før set fejloversættelser - grundet forkert
> tegnkodning, har resulteret i at oversættelsesfunktionen har returneret
> NULL. Dette vil stort set altid være resultatet, hvis indlæsning af
> første tegn fejler, eller ID er udefineret i pot-filen.

Det er vel også per definition en bug når en funktion kan returnere null
men man ikke checker om den gør det...

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kasper Nordal Lund <kasper@fakeusenet.dk> writes:

> mprotect(0xc24000, 4096, PROT_READ) = 0
> mprotect(0xbf3000, 8192, PROT_READ) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Process 5003 detached
> [root@server02 bin]#

Man får en SIGSEGV når man forsøger at tilgå en hukommelsesadresse
hvor der ikke er allokeret noget hukommelse eller at man af en eller
anden grund ikke må tilgå det på den måde man forsøger.

Ofte er det fordi man tilgår en NULL-pointer eller fordi man laver
noget fejlbehæftet pointergymnastik, eventuelt implicit ved at
overskride grænserne i et array i C.

Det er forholdsvist sjældent at det sker i et systemkald, derfor er
strace ikke umidelbart nogen hjælp. I nogle tilfælde ville man dog
kunen se at et systemkald der burde returnere en hukommelsesadresse
returnere NULL (eller '0', jeg kan ikke huske om strace fortolker
det) og så kan fejlen muligvis være at man ikke tjekker returværdien
af et systemkald.

Men det er næppe dit tilfælde. mprotect(2) skal returnere 0 når kaldet
går godt og dels ser det ud til at det meste af dit strace bare er
normal opsætniing af et program, sammenlignet med når jeg stracer
følgende program:

int main() {
char c[4];
c[10240] = 42;
}

I skal have fat i gdb så i kan finde ud af hvilken kodelinje der giver
en sigsegv.

--
http://peter.makholm.net/ | We constantly have to keep in mind why
peter@makholm.net | natural languages are good at what they're
| good at. And to never forget that Perl is a
| human language first, and a computer language
| second