V linuxových systémech byly odhaleny dvě závažné zranitelnosti – CVE-2025-6018 v rámci PAM (Pluggable Authentication Modules) a CVE-2025-6019 v knihovně libblockdev, kterou lze zneužít prostřednictvím služby udisks. Ta je součástí většiny běžně používaných distribucí, jako jsou Ubuntu, Debian nebo Fedora. Kombinací obou zranitelností může útočník s minimálním úsilím získat root přístup. Vzhledem k jednoduchosti zneužití
… více »OpenSSL Corporation zve na den otevřených dveří ve středu 20. srpna v Brně a konferenci OpenSSL od 7. do 9. října v Praze.
Něco z IT bulváru: Mark Russinovich pozval Billa Gatese, Linuse Torvaldse a Davida Cutlera na večeři a zveřejnil společné selfie. Linus se s Billem ani s Davidem do té doby nikdy osobně nesetkal. Linus a David měli na sobě červená polotrika. Mark a Bill byli v tmavém [LinkedIn].
Evropská unie nově prověřuje obchod, při němž americký miliardář Elon Musk prodal svou sociální síť X dříve známou jako Twitter vlastnímu start-upu xAI za 33 miliard dolarů (712 miliard Kč). Unijní regulační úřady zvažují, zda firmě X neudělit pokutu podle nařízení Evropské unie o digitálních službách (DSA).
Vývojáři postmarketOS vydali verzi 25.06 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Svobodný kancelářský balík ONLYOFFICE (Wikipedie) byl vydán ve verzi 9.0. Jak online Docs, tak i offline Desktop Editors. Přehled novinek také na YouTube.
Byla vydána nová verze 5.2.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
XLibre Xserver je fork X.Org Serveru. Enrico Weigelt včera oznámil vydání verze 25.0 se slovy "tento fork je nezbytným, protože je výslovným přáním většiny současné skupiny X.Org (IBM / Red Hat) opustit projekt, nechat ho navždy shnít a blokovat jakékoli podstatné příspěvky, natož nové funkce".
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Experti na kybernetickou bezpečnost potvrdili (en) největší dosud zaznamenaný únik dat. Hackeři při něm odkryli skoro 16 miliard přihlašovacích údajů z celého světa včetně účtů společností Google, Apple, Facebook, dalších sociálních sítí nebo některých serverů státní správy.
Napsal jsem mensi program na jeji odzkouseni, viz priloha lapack2.c -- funguje OK
Kdyz ji ale pouzivam tam kde ji potrebuju, tak jsou vysledky pokazde spatne, krome prvniho prvku. Napada me chyba v ukazatelich, ale podle clanku, co jsem procital tady i jinde, by to melo byt v poradku.Zkousel jsem i zapisovat do souboru jednotlive sekvence vypoctu.. vsechno je v poradku dokud nedojde na _dgesv. Ta sice spravne zapise vysledk do vstupniho pole B, ale s naprosto spatnymi cisly! Zkopiroval jsem obsah souboru B.txt a S.txt do zkouseciho programu a obdrzel jsem spravny vysledek.[overeny GNU/octave]
Muzete mi prosim vysvetlit, jaky je z pohledu te funkce rozdil v tom jestli ji dam odkaz pole, pevne dane velikosti s na pevno naplnenymi cisly, nebo odkaz dynamicky alokovane pole?
Řešení dotazu:
double
. V jedné ukázce totiž u všech předáváte pointery na int
, zatímco v druhé pointery na long
.
LVP_solveGE()
(zo suboru LVP_solver1.c) a funkciou LVP_solveG()
(zo suboru lapack2.c). V jednom su lokalne premenne typu long int
a v druhom int
. Mozno to bude v tom.
Funkce dgesv( &n, &nrhs, a, &lda, ipiv, b, &ldb, &info ) da spravny vysledek pokazde, kdyz jsou pole a a b zavedeny jako double a[121]={...}; double b[11]={...};
Kdyz se ale snazim ty pole zavest dynamicky, tak to pokazde vypocita uplne nesmysly
Zjednodusil jsem ukazku,jak to jen slo.. kdyz nahradim volani LVP_solveGE(n,S,B); za LVP_solveGE(n,as,bs); tak se dostavi spravny vysledek.
P.S.Omlouvam se, ze to vypada tak neprehledne, ale to je proste vypocet..Resp. to je neco, co "proste musi byt" v C, i kdyz je to v C zbytecne, spis az nevhodne
Funkce dgesv( &n, &nrhs, a, &lda, ipiv, b, &ldb, &info ) da spravny vysledek pokazde, kdyz jsou pole a a b zavedeny jako double a[121]={...}; double b[11]={...}; Kdyz se ale snazim ty pole zavest dynamicky, tak to pokazde vypocita uplne nesmyslyTo bude ten problem, protoze je rozdil mezi dynamicky a staticky alokovanym polem. Funkce totiz ocekava staticke pole, ktere by melo byt alokovane jako souvisly blok v pameti, zatimco dynamicky alokovane pole velikosti [n][m] je n poli velikosti m ruzne po pameti. Takze by asi bylo vhnodne ty matice definovat jako jednorozmerne pole a program prepsat.
Dost by pomohlo, kdyby ta ukázka šla přeložit bez spousty souborů, které vy máte, ale my se o jejich obsahu můžeme jen dohadovat. Pro začátek např. zkuste alokovat dynamicky pole se stejným obsahem jako mají as
a bs
a zavolat funkci na ně. Pokud bude výsledek stejný jako u staticky alokovaného (což je více než pravděpodobné), problém je jinde, než kde se ho snažíte hledat.
Ještě mne napadá: nikde nekontrolujete návratové hodnoty malloc()
, nemůže být problém v tom, že selže alokace? Jak velká je ta vaše matice?
gcc LVP_solver1.c lapack_LINUX.a lapacke.a blas_LINUX.a tmglib_LINUX.a libgfortran.so.3.0.0
Dal bych jsem i ty knihovny, ale maji dohromady 30MB.
To ted jsem prave vyzkousel pomoci tech statickych poliPro začátek např. zkuste alokovat dynamicky pole se stejným obsahem jako mají
as
abs
a zavolat funkci na ně.
as, bs
. prekopiroval jsem jejich obsah do B a S
(pred tim, nez sem volal _dgesv) pomoci
for (i=0; i<n; i++) { *(B + i) =bs[i]; }
for (i=0; i<n*n; i++) { *(S + i) =as[i]; }
Vysledek je kupodivu v poradku!
O to vic tomu ted ale nerozumim, protoze ty cisla v tech statickych polich as, bs jsem ziskal primo z tohoto programu tim, ze jsem to pole ihned po naplneni for cykly zapsal to textoveho souboru
for (i=0; i<n; i++) { *(B + i) =bs[i]; } for (i=0; i<n*n; i++) { *(S + i) =as[i]; }
Pred vsechno to naplnovani, tak to zase vyhodilo spatny vysledek..
jeste jsem za kazde to plneni matice napsal jeji vypis pomoci for (i=0; i<n; i++) {printf("%20.20f \n",*(B+i) ); }
... vsechno je v poradku,vstupy do _dgesv jsou stejne, jako v pripade pouziti statickeho pole
Hodnoty ve statických polích nejsou úplně stejné jako ty počítané, vypadá to, že jsou zaokrouhlené na šest desetinných míst. A pokud místo zkopírování statického pole dám
for (i=0; i<n; i++) { B[i] = 1E-6 * lround(1E6 * B[i]); } for (i=0; i<n; i++) { for (j=0; j<n; j++) { S[i+j*n] = 1E-6 * lround(1E6 * S[i+j*n]); } }
dostanu stejné výsledky jako se statickým polem. Takže můj tip je, že celý problém je v (ne)stabilitě té soustavy, tj. že i malá změna v koeficientech nebo pravé straně může způsobit (relativně) velkou změnu řešení. Ale nechce se mi počítat vlastní čísla, abych si to ověřil.
Tiskni
Sdílej: