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

>> Zobacz co pokazuje LogCat. Tam będzie informacja dlaczego program się
>> wywalił.
>
> 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.

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:

02-08 21:39:22.351: DEBUG/TEST(848): WARTOSC Y=0

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

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

"Adam Dybkowski" <a...@4...pl> wrote in message
news:iisd8q$6td$1@news.onet.pl...
>W dniu 2011-02-08 00:16 Lelek@ napisał(a):
>
>>> Zobacz co pokazuje LogCat. Tam będzie informacja dlaczego program się
>>> wywalił.
> 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 :-)

do góry

On 02/08/2011 05:48 PM, Lelek@ wrote:
>
> "Adam Dybkowski" <a...@4...pl> wrote in message
> news:iisd8q$6td$1@news.onet.pl...
>> W dniu 2011-02-08 00:16 Lelek@ napisał(a):
>>
>>>> Zobacz co pokazuje LogCat. Tam będzie informacja dlaczego program się
>>>> wywalił.
>> 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.

do góry

On Tue, 8 Feb 2011 23:48:49 +0100, Lelek@ wrote:
>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 :-)

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

J.

do góry

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

>> 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 :-)
>
> Jest tam jakas opcja wydruku w "assemblerze" ?
> Moze sie cos ujawni .

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.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

In the darkest hour on Wed, 09 Feb 2011 00:02:54 +0100,
J.F <j...@p...onet.pl> screamed:
>>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 :-)
>
> Jest tam jakas opcja wydruku w "assemblerze" ?
> Moze sie cos ujawni .
>

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

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:223B ]
[ 09:32:36 user up 12708 days, 21:27, 1 user, load average: 0.43, 0.10, 0.77 ]

I am not a perfectionist! (My parents were).

do góry

On 9 Lut, 09:33, "Artur M. Piwko" <m...@b...pl>
wrote:
>
> 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.

do góry

"ohouapss" <k...@g...com> wrote in message
news:19b7d58f-44f6-4c22-9a6e-f1534231e21d@v31g2000vb
s.googlegroups.com...
On 9 Lut, 09:33, "Artur M. Piwko" <m...@b...pl>
wrote:
>
> 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

public void dupa() {
byte buf[] = new byte[256];
int bfx[] = new int[256];
int i, len;

buf = FromEditText.getBytes("UTF-8");

len = buf.length;

for (i = 0; i < len; i++) {bfx[i] = ((int)buf[i] & 0xFF);}

// tu dalej kod ale niezwiązany

}

Jeżeli w polu EditText nic nie wpiszę, będzie puste to próba odczytania
buf[0] skończy się wywałką.
Pętle for można wywalić do testów nie chodzi o jej warunek < len. Pętlę
dodałem później

Zabezpieczyłem to tak:

if (len != 0) {
for (i = 0; i < len; i++) {bfx[i] = ((int)buf[i] & 0xFF);}
}

do góry

to mi wyglada na jakąś cholerną optymalizację garbage collecrion czy coś
takiego w czasie wykonywania, że nie jeżeli buf = zamiana zawartośco pola
wide charów UTF16 na UTF8 na bajty daje tylko null to tablica nie powstaje

do góry

ale jak wpiszę choćby jeden znak konwertujący się na 1 bajt w utf8 to mogę
czytać dowolny element tablicy bez wywałki.

Chodzi o to, że jeśli to:
buf = FromEditText.getBytes("UTF-8");
nie będzie miało czego czytać w polu bo nic w nie nie wpiszę

to byte Y = buf[0} czy int Y = (int)buf[0]

zamyka program "przysłowiowy ble screen" i do widzenia
zamyka aplikację

do góry