Android

In the darkest hour on Mon, 7 Feb 2011 07:11:11 +0100, Lelek@ snipped-for-privacy@nndn.pl screamed:

Tak na szybko...

byte[] buf = ...?

Dnia 07-02-2011 o 08:26:16 Artur M. Piwko snipped-for-privacy@buziaczek.pl napisał(a):

Też jestem zwolennikiem takiego zapisu, ale to raczej nie może być przyczyną problemów. Proponuję:

1. sprawdzić jak zachowuje się odczyt z tablicy deklarowanej statycznie jaki private.
2. czyścić/zerować tablicę tworzoną dynamicznie przed jej odczytem
3. używać normalnego słownictwa bo aż człowieka skręca czyta "casting" zamiast "rzutowanie"

zaznaczam, że nie znam androidowego SDK ani ichniejszej maszyny wirtualnej, to są jedynie luźne pomysły (za wyjątkiem pkt3 :))

Rzutowanie to rzutowanie, wymienic odpowiedzialnych autorow ktorzy zastosowali do C :)

P.S. Casting ? Odlewanie. I nie mamy na mysli egzaminu dla aktorek :-)

J.

W dniu 2011-02-07 12:39, Lelek@ pisze:

Pewnie wynika to z optymalizacji - alokacja zasobów dopiero przy pierwszym dostępie. W sumie niezły bat na "specjalistów" od niezainicjalizowanych zmiennych :-).

W dniu 2011-02-07 07:11, Lelek@ pisze:

int X = (int)buf; lub int X = (int)&(buf[0]);

byte Y = (byte)(buf+2);

tak lepiej?

Nie znam sdk Androida, ale dolary przeciw kamieniom, że błąd jest zupełnie gdzie indziej niż Ci się wydaje. Ta tablica powinna się automatycznie wypełnić zerami i jak najbardziej bufor istnieje.

W dniu 2011-02-07 07:11 Lelek@ napisał(a):

Zobacz co pokazuje LogCat. Tam będzie informacja dlaczego program się wywalił.

BTW: NTG?

Nie wiem co to jest LogCat :-) Od kilku dni się tym zajmuję :-). Wiem jedno, że ten buf[256] zapełniam wpisując w niego null terminated string. I jeżeli czytam poza długością wpisanego stringa to zawsze jest ten efekt ale dziwi mnie czemu mimo zadeklarowania rozmiaru on tak to traktuje. To zachowanie ma miejsce tylko dla byte. dla int tablica istnieje. Obszedłem to ale weź sobie zapodaj w kodzie takie dwie linijki, jedna deklaracja i niżej Y = buf[10] i skompiluj i uruchom. Wywałka murowana gdziekolwiek nie postawisz byle się wykonało.

W dniu 2011-02-08 00:16 Lelek@ napisał(a):

Wygląda na to, że byłem pierwszy, który to sprawdził doświadczalnie. Takie linijki dodałem na końcu onCreate w głównej mojej klasie dziedziczącej po Activity:

byte buf[] = new byte[256]; byte y = buf[10]; Log.d("TEST", "WARTOSC Y=" + String.valueOf(y));

Sprawdzałem w emulatorach 1.5 oraz 2.2. W obu przypadkach zachowanie jest identyczne i przewidywalne. Świeżo alokowany blok 256 bajtów jest standardowo wypełniony zerami i to widzę w LogCat:

Program się nie wywalił i działa normalnie. Może masz wywałkę z innego powodu...

Powiem ci, że nie mam pojęcia :-) byte y = buf[10]; Ta linijka mi załatwia sprawę :-)

Jeszcze wrócę do sprawy jutro :-) Nie daje mi to spokoju :-)

Opakuj tę linijkę w blok try/catch i zobacz czy coś się złapie. Jak wejdziesz w obsługę wyjątku, to znaczy że ta linijka bruździ. Jeśli dalej się będzie wywalać, to znaczy że co problem jest gdzieś indziej.

pzdr. j.

Jest tam jakas opcja wydruku w "assemblerze" ? Moze sie cos ujawni .

J.

W dniu 2011-02-09 00:02 J.F. napisał(a):

W Javie? Zawsze możesz zrobić disassemblację pliku classes.dex z wewnątrz instalki apk. Ale pewnie dużo się nie wyjaśni dopóki Lelek nie napisze, co mu LogCat wywala przy tym błędzie.

In the darkest hour on Wed, 09 Feb 2011 00:02:54 +0100, J.F <jfox snipped-for-privacy@poczta.onet.pl> screamed:

Da się zobaczyć jak kod wygląda na poziomie byte kodu.

Skoro ta dyskusja trwa dalej, to zanim się wytoczy takie armaty, można byłoby poprosić autora wątku o kompilowalny kawałek kodu który ma sprawiać takie problemy? Z opisu, z pierwszej wiadomości, można podejrzewać że program rzuca coś w rodzaju segfaulta a nie wyjątek. Nie wierzę w to jakoś, jeśli nie ma tam żadnego odwołania do JNI.