allocation too large for this process

**l-amoureu** · 27/04/2011, 15h54

Bonjour tout le monde

J'ai un soucis avec mon appli.
Elle fonctionne parfaitement sur mon émulateur, ainsi que sur un HD2 (MIUI) hero et wildfire, mais j'ai un soucis avec un incredible S.
Je m'explique : lors d'un clic sur un bouton, j'ai une nouvelle activity qui se lance, qui contient une ListView (dont les élément (icone, champs text) sonr a chaque fois télécharger sur internet)
Sur le incredible S, ce qu'il se passe, c'est que la listView est bien chargé, mais ca plante au bout de quelque dixième de seconde (lorsque c'est pas instantané)
Je vous met si dessous les logs, que je ne comprend pas, je n'ai jamais eu affaire a ce genre de logs.
Si quelqu'un pouvait me donner un indice, ca serait sympa

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
 
04-27 15:42:28.195: ERROR/dalvikvm-heap(5979): 202500-byte external allocation too large for this process.
04-27 15:42:28.195: ERROR/dalvikvm(5979): Out of memory: Heap Size=5259KB, Allocated=3364KB, Bitmap Size=18942KB, Limit=21436KB
04-27 15:42:28.195: ERROR/dalvikvm(5979): Trim info: Footprint=3911KB, Allowed Footprint=5767KB, Trimmed=508KB
04-27 15:42:28.195: ERROR/GraphicsJNI(5979): VM won't let us allocate 202500 bytes
04-27 15:42:28.305: INFO/DEBUG(3608): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
04-27 15:42:28.305: INFO/DEBUG(3608): Build fingerprint: 'htc_wwe/htc_vivo/vivo/vivo:2.2.1/FRG83D/335771:user/release-keys'
04-27 15:42:28.305: INFO/DEBUG(3608): pid: 5979, tid: 5979  >>> com.max <<<
04-27 15:42:28.305: INFO/DEBUG(3608): signal 11 (SIGSEGV), fault addr 00000000
04-27 15:42:28.305: INFO/DEBUG(3608):  r0 0037df70  r1 00000000  r2 00000000  r3 0037df94
04-27 15:42:28.305: INFO/DEBUG(3608):  r4 0037df70  r5 00000000  r6 00000000  r7 00000000
04-27 15:42:28.305: INFO/DEBUG(3608):  r8 bed95430  r9 418736b4  10 418736a0  fp bed95778
04-27 15:42:28.305: INFO/DEBUG(3608):  ip 0037df70  sp bed951f8  lr 00000000  pc ab14b8f4  cpsr 60000010
04-27 15:42:28.305: INFO/DEBUG(3608):  d0  414000003f800000  d1  6567647562204d38
04-27 15:42:28.305: INFO/DEBUG(3608):  d2  206f6f74206e6f39  d3  6f66206567726134
04-27 15:42:28.305: INFO/DEBUG(3608):  d4  0000000043610000  d5  4316000043610000
04-27 15:42:28.305: INFO/DEBUG(3608):  d6  3fc000003fc00000  d7  4080000080000000
04-27 15:42:28.305: INFO/DEBUG(3608):  d8  000000e143618000  d9  439580000000000f
04-27 15:42:28.305: INFO/DEBUG(3608):  d10 0000000042fc0000  d11 0000000000000000
04-27 15:42:28.305: INFO/DEBUG(3608):  d12 0000000000000000  d13 0000000000000000
04-27 15:42:28.305: INFO/DEBUG(3608):  d14 0000000000000000  d15 0000000000000000
04-27 15:42:28.315: INFO/DEBUG(3608):  d16 afd425bc47854f88  d17 0000000000000000
04-27 15:42:28.315: INFO/DEBUG(3608):  d18 0000000000000000  d19 0000000000000000
04-27 15:42:28.315: INFO/DEBUG(3608):  d20 0000000000000000  d21 0000000000000000
04-27 15:42:28.315: INFO/DEBUG(3608):  d22 0000000000000000  d23 0000000000000000
04-27 15:42:28.315: INFO/DEBUG(3608):  d24 0000000000000000  d25 0000000000000000
04-27 15:42:28.315: INFO/DEBUG(3608):  d26 0000000000000000  d27 0000000000000000
04-27 15:42:28.315: INFO/DEBUG(3608):  d28 00ff00ff00ff00ff  d29 00ff00ff00ff00ff
04-27 15:42:28.315: INFO/DEBUG(3608):  d30 0001000000010000  d31 0001000000010000
04-27 15:42:28.315: INFO/DEBUG(3608):  scr 60000012
04-27 15:42:28.385: INFO/DEBUG(3608):          #00  pc 0004b8f4  /system/lib/libskia.so
04-27 15:42:28.385: INFO/DEBUG(3608):          #01  pc 0004b9b8  /system/lib/libskia.so
04-27 15:42:28.385: INFO/DEBUG(3608):          #02  pc 00069108  /system/lib/libskia.so
04-27 15:42:28.385: INFO/DEBUG(3608):          #03  pc 00064ae8  /system/lib/libskia.so
04-27 15:42:28.385: INFO/DEBUG(3608):          #04  pc 0004f45c  /system/lib/libandroid_runtime.so
04-27 15:42:28.385: INFO/DEBUG(3608): code around pc:
04-27 15:42:28.385: INFO/DEBUG(3608): ab14b8d4 e1500001 e92d4070 e1a05001 e1a04000 
04-27 15:42:28.385: INFO/DEBUG(3608): ab14b8e4 0a00001a e1a06005 ebffff9f e1a0c004 
04-27 15:42:28.385: INFO/DEBUG(3608): ab14b8f4 e8b6000f e8ac000f e8b6000f e8ac000f 
04-27 15:42:28.385: INFO/DEBUG(3608): ab14b904 e8960003 e88c0003 e5950004 e3500000 
04-27 15:42:28.385: INFO/DEBUG(3608): ab14b914 0a000001 e2800004 ebff745c e5950000 
04-27 15:42:28.385: INFO/DEBUG(3608): code around lr:
04-27 15:42:28.385: INFO/DEBUG(3608): stack:
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951b8  afd43738  /system/lib/libc.so
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951bc  0000003b  
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951c0  0037df68  [heap]
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951c4  00000000  
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951c8  bed95430  [stack]
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951cc  418736b4  
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951d0  418736a0  
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951d4  afd0c7e7  /system/lib/libc.so
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951d8  0037df70  [heap]
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951dc  00000000  
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951e0  00000000  
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951e4  ab14b77c  /system/lib/libskia.so
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951e8  0037df70  [heap]
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951ec  00000000  
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951f0  df002777  
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951f4  e3a070ad  
04-27 15:42:28.385: INFO/DEBUG(3608): #00 bed951f8  0037df70  [heap]
04-27 15:42:28.385: INFO/DEBUG(3608):     bed951fc  bed9525c  [stack]
04-27 15:42:28.395: INFO/DEBUG(3608):     bed95200  00000000  
04-27 15:42:28.395: INFO/DEBUG(3608):     bed95204  ab14b9bc  /system/lib/libskia.so
04-27 15:42:28.395: INFO/DEBUG(3608): #01 bed95208  0037df68  [heap]
04-27 15:42:28.395: INFO/DEBUG(3608):     bed9520c  ab16910c  /system/lib/libskia.so
04-27 15:42:28.705: INFO/BootReceiver(1417): Copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_TOMBSTONE)
04-27 15:42:28.725: INFO/ActivityManager(1417): Process com.max (pid 5979) has died.
04-27 15:42:28.725: INFO/WindowManager(1417): WIN DEATH: Window{47c01390 com.max/com.max.DescriptionVinsParTrois paused=false}
04-27 15:42:28.725: INFO/WindowManager(1417): WIN DEATH: Window{47b7b948 com.max/com.max.Main paused=false}

Cordialement

EDIT : j'ai trouvé au moins une partis du problème (mais je sais pas comment résoudre)

C'est dans la partie getView de mon adapter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Bitmap logo = BitmapFactory.decodeResource(mContext.getResources(), mContext.getResources().getIdentifier("com.max:drawable/logo_vinoreco_icon",null,null));
holder.imageVin.setImageBitmap(logo);

L'image ne serait t'elle donc pas chargé correctement ?

**Ryu2000** · 27/04/2011, 16h07

Au pif je pense que c'est ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Bitmap Size=18942KB, Limit=21436KB

T'as déjà : 18 942 Kb pour les bitmaps et la limite c'est : 21 436 Kb.

Tu peux pas télécharger 10 Mo d'images.

Je suppose que le but du jeu c'est que :
Heap Size + Allocated + Bitmap Size < Limit.

Essaie avec moins d'images et des images moins lourde, peut être que je dis pas que des conneries.

**l-amoureu** · 27/04/2011, 16h35

Essaie avec moins d'images et des images moins lourde, peut être que je dis pas que des conneries.

J'y ai pensé, mais le truc, c'est que je n'ai que 3 images a chaque fois, de moins de 10Ko chacune.

Je me dis que c'est peut être du au fait que les images téléchargées ne sont pas recyclées lorsque je n'en ai plus besoin (c'est peut être important, parce que je peux actualiser la liste avec 3 nouvelles images, donc les ancienne ne servent plus)

Le comportement initial devrait être : si l'image a télécharger n'est pas l'image par défaut, on la télécharge puis on l'affiche, sinon, on la télécharge pas, et on affiche celle en local.

Je viens de faire en sorte que les images soient maintenant a chaque fois téléchargée, pour ne plus avoir a prendre celle en local, et j'ai presque plus de problème (d'où l'importance de pouvoir recycler les ancienne images, celle que sont écrasés par les nouvelles lors de l'actualisation de la listView)
Et, ca me fait rester sur mon avis premier, il y a un soucis au niveau des image en local, mais je comprend pas du tout pourquoi (surtout que d'autre activity de mon appli les utilise, sans soucis)

**Ryu2000** · 28/04/2011, 09h04

Je crois que quelqu'un avait le même problème que toi, mais ça devait être du au debugger ou au Thread.

Et pour certains cette phrase à aidé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

The framework will often capture views onscreen into temporary bitmaps for drawing performance. It looks like your app is pushing right up against its memory limit already and this bumps it over. Take a look at the other suggestions for limiting your app's memory usage.

Elle marche comme ton application, il y a beaucoup d'Activities ?
Des threads ?

**Feanorin** · 28/04/2011, 10h23

Bonjour,

Vu le problème d'espaces mémoire , il ne faut pas oublier que les applications sur smartphone ont un espace mémoire limité , et par conséquent il est préférable de ne pas travailler avec des grosses sources de mémoires.

Essaye de faire un scale sur tes images lorsque celle-ci commencent a devenir imposante.

De plus n'oublies pas qu'il faut nettoyer les bitmaps via un recycle. Sinon l'allocation reste en mémoire.

**l-amoureu** · 28/04/2011, 10h42

Merci pour vos deux réponse.
J'ai tenté de faire des recherche avec notamment la phrase de thierrybenji, mais sans grand succés.

Le principe, pour faire vite (mais bien expliquer quand même) :
J'ai une activité qui contient une liste view.
Lors de l'affichage de cette activity (si on peux dire ca comme ca), je lance un thread pour télécharger un json qui contient 3 item (chaque item contient des champs text, ainsi que une url pour une image).
Une fois que le téléchargement du json est terminé, je donne a l'adapter de ma liste différent paramètre, dont le json (en gros, pour faire simple).

Et, dans la classe adapter, j'analyse pour chaque item les champs text a afficher, et je lance un thread pour télécharger l'image liée a l'url.

Donc, dans le cas de base où je télécharge les image des mes 3 item, j'ai en tout 4 thread de lancé (1 pour télécharger le json, et 1 pour chaque item)

Et, pour éclaircir les chose, les images font au plus 80x80 px, et au maximum une 20aine de Ko.

Ensuite, pour répondre à Feanorin, comment est ce que je peux nettoyer les bitmaps ?
Parce que, a chaque nouveau json téléchargé, je fais ca dans mon handler :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MAdapter adpt = new MAdapter(mContext,json);
adpt.notifyDataSetChanged();
list.setAdapter(adpt);

je ne vois donc pas de moyen de faire un recycle sur mes bitmap, je n'ai pas d'accès direct aux bitmaps téléchargée, non ?
Et, en plus, a raison de 20Ko par image, fois 3 pour tout les item, et en majorant, ca me ferait du 100Ko de perdu par actualisation, or, au bout de parfois une seul actualisation, j'ai cette erreur.

De ce que j'en ai compris, ca pourrait provenir du débugger, mais j'arrive pas a le désactiver (même en mettant l'option dans le manifest)

**Feanorin** · 28/04/2011, 11h14

Bonjour,

je ne vois donc pas de moyen de faire un recycle sur mes bitmap, je n'ai pas d'accès direct aux bitmaps téléchargée, non ?

Ce n'est pas les bitmaps qui faut recycler mais l'objet Bitmap que tu utilises pour les afficher dans ta listview
http://developer.android.com/referen...#recycle%28%29

Il faut les recycler avant de changer le cache de ta view ( donc avant de changer l'image ).

Et, en plus, a raison de 20Ko par image, fois 3 pour tout les item, et en majorant, ca me ferait du 100Ko de perdu par actualisation, or, au bout de parfois une seul actualisation, j'ai cette erreur

La dessus je suis d'accord mais ce n'est pas ce que t'indiques le logcat , as tu vérifié que les images que tu récupérais dans le code ne pesait que 10ko ?

Bitmap Size=18942KB

**l-amoureu** · 28/04/2011, 12h31

Bon, j'ai rajouté un System.gc() dans mon getView (dans la class adapter), ca semble résoudre globalement mon soucie.
Mais, je reste peu convaincu, j'aimerais quand même faire du recycle sur les bitmap, mais j'ai pas réussi, ca me faisait une erreur (capté dans un try catch, mais quand même):

j'avais mis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

holder.imageBouteille.getDrawingCache().recycle();

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
04-28 12:29:02.571: WARN/System.err(5245): java.lang.NullPointerException
04-28 12:29:02.571: WARN/System.err(5245):     at com.max.DescriptionVinsAdapter.selectionIconBouteille(DescriptionVinsAdapter.java:193)
04-28 12:29:02.571: WARN/System.err(5245):     at com.max.DescriptionVinsAdapter.getView(DescriptionVinsAdapter.java:154)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.AbsListView.obtainView(AbsListView.java:1336)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.ListView.makeAndAddView(ListView.java:1775)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.ListView.fillDown(ListView.java:654)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.ListView.fillSpecific(ListView.java:1328)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.ListView.layoutChildren(ListView.java:1606)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.AbsListView.onLayout(AbsListView.java:1165)
04-28 12:29:02.571: WARN/System.err(5245):     at android.view.View.layout(View.java:7280)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.RelativeLayout.onLayout(RelativeLayout.java:909)
04-28 12:29:02.571: WARN/System.err(5245):     at android.view.View.layout(View.java:7280)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.RelativeLayout.onLayout(RelativeLayout.java:909)
04-28 12:29:02.571: WARN/System.err(5245):     at android.view.View.layout(View.java:7280)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.FrameLayout.onLayout(FrameLayout.java:333)
04-28 12:29:02.571: WARN/System.err(5245):     at android.view.View.layout(View.java:7280)
04-28 12:29:02.571: WARN/System.err(5245):     at android.widget.FrameLayout.onLayout(FrameLayout.java:333)
04-28 12:29:02.571: WARN/System.err(5245):     at android.view.View.layout(View.java:7280)
04-28 12:29:02.571: WARN/System.err(5245):     at android.view.ViewRoot.performTraversals(ViewRoot.java:1049)
04-28 12:29:02.571: WARN/System.err(5245):     at android.view.ViewRoot.handleMessage(ViewRoot.java:1748)
04-28 12:29:02.571: WARN/System.err(5245):     at android.os.Handler.dispatchMessage(Handler.java:99)
04-28 12:29:02.571: WARN/System.err(5245):     at android.os.Looper.loop(Looper.java:143)
04-28 12:29:02.571: WARN/System.err(5245):     at android.app.ActivityThread.main(ActivityThread.java:5127)
04-28 12:29:02.571: WARN/System.err(5245):     at java.lang.reflect.Method.invokeNative(Native Method)
04-28 12:29:02.571: WARN/System.err(5245):     at java.lang.reflect.Method.invoke(Method.java:521)
04-28 12:29:02.571: WARN/System.err(5245):     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:858)
04-28 12:29:02.581: WARN/System.err(5245):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
04-28 12:29:02.581: WARN/System.err(5245):     at dalvik.system.NativeStart.main(Native Method)

**Feanorin** · 28/04/2011, 13h36

Bonjour,

un exemple pour recycler une image :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
private void changeImage() {
     if (mCurrentImage != null) {
          mCurrentImage.recycle();
          mCurrentImage = null;
     }
     mCurrentImage = getNewImage();
}

**l-amoureu** · 28/04/2011, 14h31

Merci pour tes conseils

Mais, le soucis, comme je l'ai dit, ce n'est pas de recycler une image, ca je sais faire, mais c'est d'abord de trouver l'image a recycler : c'est une listView, et je sais pas comment récupérer les bitmap pour ensuite les recycler.

**Ryu2000** · 28/04/2011, 15h00

Moi j'ai une classe contenant 2 String et un Bitmap et avec ça je construis une ListView.

Du coup j'ai une ArrayList<cetteClasse> et j'ai pas de problème d'allocation de mémoire.

**Feanorin** · 10/05/2011, 18h19

Bonjour,

c'est une listView, et je sais pas comment récupérer les bitmap pour ensuite les recycler.

Il faudrait que tu les recycle lorsque tu changes leur bitmaps . Si c'est le cas .

Après es-tu sûr que cela provient d'une fuite mémoire , si le problème provient d'un manque d'un recycle dans ton code normalement tu verras ton espace mémoire augmenter jusqu'à exploser .

allocation too large for this process

Android

Discussions similaires

Partager

Partager