Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 14. March 2007, 15:41 MES (#7)
|
|
|
|
|
...weil:
""
I guess googlemalloc (tcmalloc?) isn't suitable for a general purpose glibc allocator.
""
EOQ (http://lkml.org/lkml/2007/3/13/148)
Und wo der Haken im glibc-malloc liegt haben sie wohl noch nicht gefunden :-/
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 14. March 2007, 11:19 MES (#2)
|
|
|
|
|
Das Problem soll gelöst sein:
hier
entweder man nimmt nicht die glibc oder es ist im userspace zu finden?
Ich kenne mich hier nicht so gut aus ...
|
|
|
|
|
|
|
|
|
|
|
|
|
Na, kaum ist die Meldung draussen startet ein Dutzend Programmierer durch, lokalisiert das Problem und findet eine Alternative zur Stadardlibrary, die das Problem bereits löst und mit wenigen Handgriffen installiert werden kann.
Analysieren können die Closed Source Anbieter auch, wenn sie gross genug sind, aber ihr Geschäftsmodell erschwert oder verhindert, dass ein anderer bereits die Lösung programmiert hat (ob nun absichtlich oder aus Versehen) und man dessen Lösung einfach
rasch einbaut.
Grüsse vom Knochen --
Ein christlich Regiment wird durch nichts mehr verhunzt als durch zu viel sogenannte Justiz. J. Gotthelf
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 14. March 2007, 13:10 MES (#4)
|
|
|
|
|
ein wunder dass hier noch nichts zu dem thema steht: http://blog.fefe.de/ er zieht doch sonst immer so über die glibc her und promoted seine dietlibc (oder verwechsle ich jetzt personen und/oder projekte?)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Vergiss die dietlibc, aus zwei Gründen.
1.) compiliert fast garnichts damit
2.) werden damit compilierte Programme statisch gelinkt, bei einem dietlibc-update darfst du also alles recompilieren.
Wenn du eine funktionierende glibc-alternative willst, schau dir die uClibc an.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 14. March 2007, 14:07 MES (#6)
|
|
|
|
|
Wenns doch statisch gelinkt ist, dann muss man doch gar nichts neu compilieren, weil ja eh schon alles im entsprechenden Binary ist? Sonst waers ja dynamisch, weil dann dynamisch etwas dazu geladen wird.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, aber wenn die Lib ein Sicherheitsloch hat kannst Du sie nicht austauschen, ohne das gesamte Binary neu zu bauen oder zu warten, bis das jemand für Dich gemacht hat.
Grüsse vom Knochen --
Ein christlich Regiment wird durch nichts mehr verhunzt als durch zu viel sogenannte Justiz. J. Gotthelf
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 14. March 2007, 15:53 MES (#9)
|
|
|
|
|
Es wäre sehr unprofessionell, um nicht zu sagen, dumm und kindisch[1], wegen eines Problems die komplette Implementation zu wechseln. Nein, das wäre gar religiös. Sachlich dagegen ist es, das Problem zu lokalisieren und dann zu beheben.
[1] Sorry Kinder, viele Erwachsene sind sicherlich dümmer als ihr.
|
|
|
|
|
|
|
|
|
|
|
|
|
Aber wenn man die Implementation wechselt, dann hat man das Problem schon zumindest grob lokalisiert. Schon weiß man, dass das Problem in der glibc ist und kann nun versuchen es zu beheben.
Also gar nicht religiös oder kindisch sondern einfach sehr praktisch zu Debuggingzwecken.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 15. March 2007, 01:36 MES (#11)
|
|
|
|
|
Wenn es gar nicht erst kompiliert oder einfach nur crasht, dann bist du so schlau wie vorher. Es gibt schon einen Unterschied zwischen systematischem Vorgehen und Schaun-mer-mal. Man kann z.B. einfach einen Profiler nutzen. Dann sieht man sehr schnell, wo viel CPU-Zeit verbraten wird.
|
|
|
|
|
|
|
|
|
|
|
|
|
Aber da es kompiliert hat und beim starten nicht crasht ist sofort klar woran das liegt.
Klar, mit einem Profiler würde das wohl auch gehen. Aber so ist das für die Grobeingrenzung auch effaktiv.
Von Kindisch hier zu sprechen finde ich auf jeden Fall stark übertrieben.
|
|
|
|
|
|
|
|
|
|
|
|
|
<a href="http://blog.fefe.de/?ts=bb063d77">Bitteschön</a>, er hat was dazu geschrieben. Fefe erstaunt mich manchmal, denn ich habe mich genau das gleiche gefragt, warum da nichts zu lesen war.
|
|
|
|
|
|