Huge amount of memory used by flink - scala
Since the last couple week I build a DataStream programs in Flink in scala.
But I have a strange behavior, flink uses lots of more memory than I expected.
I have a 4 ListState of tuple(Int, long) in my processFunction keyed by INT, I use it to get different unique Counter in a different time frame, and I expected the most of the memory was used by this List.
But it's not the case.
So I print an histo live of the JVM.
And I was surprised how many memories are used.
num #instances #bytes class name
----------------------------------------------
1: 138920685 6668192880 java.util.HashMap$Node
2: 138893041 5555721640 org.apache.flink.streaming.api.operators.InternalTimer
3: 149680624 3592334976 java.lang.Integer
4: 48313229 3092046656 org.apache.flink.runtime.state.heap.CopyOnWriteStateTable$StateTableEntry
5: 14042723 2579684280 [Ljava.lang.Object;
6: 4492 2047983264 [Ljava.util.HashMap$Node;
7: 41686732 1333975424 com.myJob.flink.tupleState
8: 201 784339688 [Lorg.apache.flink.runtime.state.heap.CopyOnWriteStateTable$StateTableEntry;
9: 17230300 689212000 com.myJob.flink.uniqStruct
10: 14025040 561001600 java.util.ArrayList
11: 8615581 413547888 com.myJob.flink.Data$FingerprintCnt
12: 6142006 393088384 com.myJob.flink.ProcessCountStruct
13: 4307549 172301960 com.myJob.flink.uniqresult
14: 4307841 137850912 com.myJob.flink.Data$FingerprintUniq
15: 2153904 137849856 com.myJob.flink.Data$StreamData
16: 1984742 79389680 scala.collection.mutable.ListBuffer
17: 1909472 61103104 scala.collection.immutable.$colon$colon
18: 22200 21844392 [B
19: 282624 9043968 org.apache.flink.shaded.netty4.io.netty.buffer.PoolThreadCache$MemoryRegionCache$Entry
20: 59045 6552856 [C
21: 33194 2655520 java.nio.DirectByteBuffer
22: 32804 2361888 sun.misc.Cleaner
23: 35 2294600 [Lscala.concurrent.forkjoin.ForkJoinTask;
24: 640 2276352 [Lorg.apache.flink.shaded.netty4.io.netty.buffer.PoolThreadCache$MemoryRegionCache$Entry;
25: 32768 2097152 org.apache.flink.core.memory.HybridMemorySegment
26: 12291 2082448 java.lang.Class
27: 58591 1874912 java.lang.String
28: 8581 1372960 java.lang.reflect.Method
29: 32790 1311600 java.nio.DirectByteBuffer$Deallocator
30: 18537 889776 java.util.concurrent.ConcurrentHashMap$Node
31: 4239 508680 java.lang.reflect.Field
32: 8810 493360 java.nio.HeapByteBuffer
33: 7389 472896 java.util.HashMap
34: 5208 400336 [I
The tupple(Int, long) is com.myJob.flink.tupleState in 7th position.
And I see the tuple use less than 2G of memory.
I don't understand why flink used this amount of memory for these classes.
Can anyone give me a light on this behavior, thanks in advance.
Update:
I run my job on a stand alone cluster (1 jobManager, 3 taskManager)
the flink version is 1.5-SNAPSHOT commit : e4486ae
I get the histo live on one taskManager node.
Update 2 :
In my processFunction I used :
ctx.timerService.registerProcessingTimeTimer(ctx.timestamp + 100)
And after on onTimer function, I process my listState to check all old data.
so it create a timer for each call on processFunction.
but why the timer is steel on memory after onTimer function triggered
How many windows do you end up with? Based on the top two entries what are are seeing is the "timers" that are used by Flink to track when to clean up the window. For every key in the window you will end up with (key, endTimestamp) effectively in the timer state. If you have a very large number of windows (perhaps out of order time or delayed watermarking) or a very large number of keys in each window, those will each take up memory.
Note that even if you are using RocksDB state, the TimerService uses Heap memory so you have to watch out for that.
Related
Mapbox in Android - Black color around GEOTiff raster layers
Goal I need to add some aeronautical layers taken from FAA to the map. The layers are provided as GeoTIFF files. Steps Downloaded a GeoTiff file from FAA website. Using QGis app clipped the legend from the file. Actually the issue occurs without this step as well. Reprojected it to EPSG:3857 using GDAL command gdalwarp -q -t_srs EPSG:3857 -dstalpha -of vrt Albuquerque\ SEC\ 104-cut.tif /vsistdout/ | gdal_translate -co compress=lzw /vsistdin/ Albuquerque\ SEC\ 104-north-up-cut.tif. Otherwise I got Error creating Mapnik Datasource: Invalid raster: Invalid rotation value in geotransform array when uploading to Mapbox. Created a Tileset by uploading GeoTIFFs to Mapbox. Created a new style in the Mapbox Studio. Added the tilesets as layers. Mapbox Studio Result The map is showing well in Mapbox Studio: Android Result However in Android app this style shows with some black borders of random width depending on zoom level and camera position. Here is how it looks in android: I tried it on Pixel 3a (Android 10), Nexus 5x (Android 8.1) and Android emulator (Android 10). I have good internet connection and gave it enough time so the tiles are loaded. The source code where the map is embedded is official Demo app. I just replaced token and style URL: mapView.getMapAsync(new OnMapReadyCallback() { #Override public void onMapReady(#NonNull MapboxMap mapboxMap) { DefaultStyleActivity.this.mapboxMap = mapboxMap; mapboxMap.setStyle("mapbox://styles/rustamg/ck8se724l23bh1io2b1hnbqls"); } }); Here is GDALInfo for the GEOTiff I uploaded: Driver: GTiff/GeoTIFF Files: /Users/me/Desktop/Dev/Albuquerque SEC 104-north-up-cut.tif Size is 16104, 11408 Coordinate System is: PROJCS["WGS 84 / Pseudo-Mercator", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]], PROJECTION["Mercator_1SP"], PARAMETER["central_meridian",0], PARAMETER["scale_factor",1], PARAMETER["false_easting",0], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AXIS["X",EAST], AXIS["Y",NORTH], EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=#null +wktext +no_defs"], AUTHORITY["EPSG","3857"]] Origin = (-12154316.342745549976826,4340308.343459489755332) Pixel Size = (51.194510520863538,-51.194510520863538) Metadata: AREA_OR_POINT=Area TIFFTAG_DATETIME=2019:09:03 09:02:22 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) TIFFTAG_SOFTWARE=Adobe Photoshop CC (Windows) TIFFTAG_XRESOLUTION=300 TIFFTAG_YRESOLUTION=300 Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-12154316.343, 4340308.343) (109d11' 2.69"W, 36d17'16.43"N) Lower Left (-12154316.343, 3756281.367) (109d11' 2.69"W, 31d56'47.16"N) Upper Right (-11329879.945, 4340308.343) (101d46'40.96"W, 36d17'16.43"N) Lower Right (-11329879.945, 3756281.367) (101d46'40.96"W, 31d56'47.16"N) Center (-11742098.144, 4048294.855) (105d28'51.82"W, 34d 8'42.17"N) Band 1 Block=16104x1 Type=Byte, ColorInterp=Palette Mask Flags: PER_DATASET ALPHA Color Table (RGB with 256 entries) 0: 255,255,255,255 1: 255,255,0,255 2: 255,0,255,255 3: 255,0,0,255 4: 0,255,255,255 5: 0,255,0,255 6: 0,0,255,255 7: 0,0,0,255 8: 252,252,254,255 9: 255,255,1,255 10: 252,236,170,255 11: 248,228,166,255 12: 228,200,154,255 13: 154,81,86,255 14: 120,103,105,255 15: 221,135,154,255 16: 166,87,106,255 17: 107,86,91,255 18: 172,104,124,255 19: 79,9,35,255 20: 141,59,88,255 21: 126,12,61,255 22: 229,107,161,255 23: 200,150,173,255 24: 234,178,204,255 25: 100,8,53,255 26: 200,81,137,255 27: 146,68,105,255 28: 136,38,88,255 29: 98,29,64,255 30: 190,113,151,255 31: 119,44,83,255 32: 214,182,199,255 33: 177,144,163,255 34: 116,13,75,255 35: 33,8,25,255 36: 143,116,141,255 37: 232,216,232,255 38: 248,232,248,255 39: 77,26,86,255 40: 75,69,104,255 41: 105,103,125,255 42: 40,36,105,255 43: 8,8,24,255 44: 232,232,248,255 45: 120,120,122,255 46: 8,14,85,255 47: 203,204,216,255 48: 60,62,80,255 49: 8,22,115,255 50: 86,88,104,255 51: 180,184,201,255 52: 8,54,179,255 53: 8,40,120,255 54: 28,56,120,255 55: 8,40,104,255 56: 143,152,171,255 57: 8,54,136,255 58: 37,47,65,255 59: 184,201,232,255 60: 25,72,152,255 61: 202,214,233,255 62: 31,56,95,255 63: 8,84,182,255 64: 8,72,158,255 65: 8,56,120,255 66: 9,42,86,255 67: 25,72,136,255 68: 37,88,152,255 69: 51,75,104,255 70: 11,100,202,255 71: 8,23,40,255 72: 27,72,120,255 73: 8,56,104,255 74: 44,88,133,255 75: 184,198,212,255 76: 80,84,88,255 77: 8,72,133,255 78: 22,104,178,255 79: 71,121,168,255 80: 91,134,173,255 81: 43,121,184,255 82: 80,113,140,255 83: 8,88,152,255 84: 24,88,136,255 85: 53,104,143,255 86: 8,88,136,255 87: 22,104,149,255 88: 114,144,162,255 89: 139,172,191,255 90: 104,124,134,255 91: 146,205,232,255 92: 136,197,216,255 93: 134,184,201,255 94: 153,200,216,255 95: 135,216,232,255 96: 85,105,109,255 97: 213,233,236,255 98: 152,195,200,255 99: 167,216,221,255 100: 181,232,237,255 101: 151,233,237,255 102: 8,24,24,255 103: 230,248,248,255 104: 182,183,183,255 105: 184,217,216,255 106: 120,136,134,255 107: 24,40,37,255 108: 174,207,200,255 109: 143,147,145,255 110: 225,248,232,255 111: 103,120,104,255 112: 8,24,8,255 113: 87,104,86,255 114: 212,232,210,255 115: 181,200,175,255 116: 163,171,158,255 117: 229,248,216,255 118: 198,216,184,255 119: 147,172,126,255 120: 231,248,200,255 121: 200,216,168,255 122: 216,232,178,255 123: 200,216,151,255 124: 232,248,184,255 125: 212,232,146,255 126: 232,248,167,255 127: 189,207,105,255 128: 199,200,152,255 129: 248,248,71,255 130: 24,24,8,255 131: 145,144,57,255 132: 248,248,104,255 133: 216,216,135,255 134: 248,248,168,255 135: 200,200,136,255 136: 216,216,152,255 137: 232,232,168,255 138: 248,248,184,255 139: 216,216,168,255 140: 232,232,184,255 141: 248,248,200,255 142: 200,200,168,255 143: 120,120,101,255 144: 232,232,200,255 145: 248,248,216,255 146: 216,216,193,255 147: 200,200,184,255 148: 232,232,216,255 149: 248,248,232,255 150: 170,168,56,255 151: 201,194,72,255 152: 179,174,78,255 153: 229,223,101,255 154: 214,205,88,255 155: 196,189,104,255 156: 232,218,133,255 157: 246,233,151,255 158: 42,40,29,255 159: 148,136,82,255 160: 200,184,120,255 161: 216,200,136,255 162: 232,216,152,255 163: 248,232,168,255 164: 165,152,104,255 165: 114,106,76,255 166: 182,173,141,255 167: 248,216,115,255 168: 183,168,119,255 169: 147,139,114,255 170: 200,168,72,255 171: 216,184,88,255 172: 200,184,136,255 173: 216,200,152,255 174: 232,216,168,255 175: 248,232,184,255 176: 228,184,72,255 177: 200,168,88,255 178: 216,184,104,255 179: 81,74,58,255 180: 248,188,71,255 181: 232,185,88,255 182: 248,199,101,255 183: 200,168,104,255 184: 216,184,120,255 185: 232,200,136,255 186: 248,216,152,255 187: 168,152,120,255 188: 200,184,152,255 189: 216,200,168,255 190: 232,216,184,255 191: 219,167,72,255 192: 178,144,82,255 193: 248,231,200,255 194: 184,136,56,255 195: 216,168,88,255 196: 232,185,104,255 197: 248,200,123,255 198: 220,150,49,255 199: 130,93,40,255 200: 200,152,84,255 201: 184,152,104,255 202: 200,168,120,255 203: 216,184,136,255 204: 232,200,152,255 205: 248,216,168,255 206: 179,119,36,255 207: 160,114,54,255 208: 216,168,104,255 209: 232,184,120,255 210: 200,137,56,255 211: 232,168,88,255 212: 61,53,43,255 213: 146,115,80,255 214: 216,168,120,255 215: 248,200,152,255 216: 168,136,104,255 217: 184,152,120,255 218: 200,168,136,255 219: 216,184,152,255 220: 232,200,168,255 221: 248,216,184,255 222: 216,200,184,255 223: 248,232,216,255 224: 110,87,68,255 225: 248,184,135,255 226: 170,151,137,255 227: 184,136,104,255 228: 200,152,120,255 229: 216,168,136,255 230: 232,184,150,255 231: 248,200,168,255 232: 171,114,77,255 233: 168,136,120,255 234: 232,200,184,255 235: 200,183,174,255 236: 232,164,134,255 237: 200,168,154,255 238: 248,167,139,255 239: 171,119,104,255 240: 216,168,154,255 241: 184,133,121,255 242: 140,117,111,255 243: 232,213,208,255 244: 201,148,137,255 245: 235,181,172,255 246: 216,138,126,255 247: 41,24,23,255 248: 24,8,8,255 249: 248,232,232,255 250: 201,200,200,255 251: 248,248,248,255 252: 232,232,232,255 253: 104,104,104,255 254: 24,24,24,255 255: 8,8,8,255 Band 2 Block=16104x1 Type=Byte, ColorInterp=Alpha Question How can I get rid of those black issues? I'd be happy to provide more info if needed. Update 2020-05-06 I tried what's suggested in troubleshooting page: both prepare tileset and create RasterSource within Android app. The first command rio calc "(asarray (take a 1) (take a 2) (take a 3))" --co compress=lzw --co tiled=true --co blockxsize=256 --co blockysize=256 --name a=filename.tif filename255.tif failed with an error: IndexError: index 1 is out of bounds for size 1 However my tif already uses LZW compression. So I tried the second command: rio edit-info --nodata 0 filename255.tif and uploaded the result to Mapbox. The result was the same except that white background of the image became black as well: I also tried the same steps with smaller image (409x306) as it's pointed here that Android has texture size limitation. The result is all the same:
The black borders should be transparent, but the raster image format Mapbox is using (JPG) does not support transparency, which is a known issue that exists in every gl-native-based SDK. This issue presents itself when you reference a style that has the raster layer built in. As a workaround, you can follow Mapbox's troubleshooting guide on troubleshooting raster images with black backgrounds to make your tileset transparent and then add the tileset as a RasterSource within your Android application to display the raster tile as expected. Please take a look at the following example as a reference for adding a RasterSource: Add a WMS Source Instead of calling the rasterSource using "mapbox://username.tilesetID", you need to call it similarly to the Add a WMS Source example. The code below will resolve your issue: style.addSource(RasterSource( "albuquerque-source", TileSet( "tileset", "https://api.mapbox.com/v4/<username.tilesetID>/{z}/{x}/{y}.png?access_token=<your_access_token>" ), 256 ))
mapbox gl fill-extrusion-height restriction decimal values in meter
I was trying to model a detailed building with fill-extrusion feature of mapbox, but I experienced that it takes height in multiplication of 1 meter only. Please see this JSFiddle: `http://jsfiddle.net/parveenkaloi/p5w1je7s/20/` I've set 9 boxes in these sizes (meters): 1: 0.25m, 2: 0.5m, 3: 0.75m, 4: 1.0m, 5: 1.25m, 6: 1.5m, 7: 1.75m, 8: 2.0m, 9: 2.25m but in result height is : 1: 0.0m, 2: 0.0m, 3: 0.0m, 4: 1.0m, 5: 1.0m, 6: 1.0m, 7: 1.0m, 8: 2.0m, 9: 2.0m Please help me, if there is any solution for this. Thanks
You use the old version of the mapbox-gl-js library - v0.38.0. Try latest v0.47.0. There is also a shorter record for obtaining values - via expressions: "paint": { 'fill-extrusion-color': ["get", "clr"], 'fill-extrusion-height': ["get", "ht" ], 'fill-extrusion-base': ["get", "pz" ] } [ http://jsfiddle.net/n3zvs9jm/1/ ]
What is the purpose of Flux::sampleTimeout method in the project-reactor API?
The Java docs say the following: Emit the last value from this Flux only if there were no new values emitted during the time window provided by a publisher for that particular last value. However I found the above description confusing. I read in gitter chat that its similar to debounce in RxJava. Can someone please illustrate it with an example? I could not find this anywhere after doing a thorough search.
sampleTimeout lets you associate a companion Flux X' to each incoming value x in the source. If X' completes before the next value is emitted in the source, then value x is emitted. If not, x is dropped. The same processing is applied to subsequent values. Think of it as splitting the original sequence into windows delimited by the start and completion of each companion flux. If two windows overlap, the value that triggered the first one is dropped. On the other side, you have sample(Duration) which only deals with a single companion Flux. It splits the sequence into windows that are contiguous, at a regular time period, and drops all but the last element emitted during a particular window. (edit): about your use case If I understand correctly, it looks like you have a processing of varying length that you want to schedule periodically, but you also don't want to consider values for which processing takes more than one period? If so, it sounds like you want to 1) isolate your processing in its own thread using publishOn and 2) simply need sample(Duration) for the second part of the requirement (the delay allocated to a task is not changing). Something like this: List<Long> passed = //regular scheduling: Flux.interval(Duration.ofMillis(200)) //this is only to show that processing is indeed started regularly .elapsed() //this is to isolate the blocking processing .publishOn(Schedulers.elastic()) //blocking processing itself .map(tuple -> { long l = tuple.getT2(); int sleep = l % 2 == 0 || l % 5 == 0 ? 100 : 210; System.out.println(tuple.getT1() + "ms later - " + tuple.getT2() + ": sleeping for " + sleep + "ms"); try { Thread.sleep(sleep); } catch (InterruptedException e) { e.printStackTrace(); } return l; }) //this is where we say "drop if too long" .sample(Duration.ofMillis(200)) //the rest is to make it finite and print the processed values that passed .take(10) .collectList() .block(); System.out.println(passed); Which outputs: 205ms later - 0: sleeping for 100ms 201ms later - 1: sleeping for 210ms 200ms later - 2: sleeping for 100ms 199ms later - 3: sleeping for 210ms 201ms later - 4: sleeping for 100ms 200ms later - 5: sleeping for 100ms 201ms later - 6: sleeping for 100ms 196ms later - 7: sleeping for 210ms 204ms later - 8: sleeping for 100ms 198ms later - 9: sleeping for 210ms 201ms later - 10: sleeping for 100ms 196ms later - 11: sleeping for 210ms 200ms later - 12: sleeping for 100ms 202ms later - 13: sleeping for 210ms 202ms later - 14: sleeping for 100ms 200ms later - 15: sleeping for 100ms [0, 2, 4, 5, 6, 8, 10, 12, 14, 15] So the blocking processing is triggered approximately every 200ms, and only values that where processed within 200ms are kept.
Unnecessary load and store instruction in scala's byte code
I just did some inverstigation on pattern match and its corresponding byte code. val a = Array(1,2,3,4) a.map { case i => i + 1 } For above code, I use javap and got the byte code for the annonymous function inside map: public int apply$mcII$sp(int); Code: 0: iload_1 1: istore_2 2: iload_2 3: iconst_1 4: iadd 5: ireturn So it seems to me that in line 0 we push an int (the parameter), then in line 1 we load the int and in line 2 we push it back ... What's the purpose here? Thanks!
Dude, try -optimise. public int apply$mcII$sp(int); flags: ACC_PUBLIC Code: stack=2, locals=2, args_size=2 0: iload_1 1: iconst_1 2: iadd 3: ireturn Use scala> :javap -prv - and then something like scala> :javap -prv $line4/$read$$iw$$iw$$anonfun$1
This is not really an answer, since I couldn't figure out why this happens. I'm hoping that these observations will be at least helpful :) I'm seeing the following bytecode in Scala 2.10: public int apply$mcII$sp(int); Code: 0: iload_1 ; var1 -> stack 1: istore_2 ; var2 <- stack 2: iload_2 ; var2 -> stack 3: iconst_1 ; 1 -> stack 4: iadd 5: istore_3 ; var3 <- stack 6: iload_3 ; var3 -> stack 7: ireturn ; return <- stack The first two instructions seem to simply move the value of var1 to var2, then move var2 to the stack as a parameter. The same can be observed after iadd, where the result is stored in var3 for no apparent reason, since ireturn returns the value from the stack anyway.
[AVPlaybackItem fpItem]: message sent to deallocated instance
I play a movie with MPMoviePlayerController. Later, the app is "restarted" (meaning a pseudo-reset, where all viewControllers are removed and the user returns to the home screen), and the same movie is played again. This leads to a crash in iOS 3.2.2 on the iPad: [AVPlaybackItem fpItem]: message sent to deallocated instance I have no idea where that comes from. Seems to be something private. Has anyone experienced and possibly solved the same problem? The stack trace for that particular address: (gdb) info malloc 0x11471400 Alloc: Block address: 0x11471400 length: 76 Stack - pthread: 0xa0630500 number of frames: 34 0: 0x9534e0c3 in malloc_zone_calloc 1: 0x9534e01a in calloc 2: 0x343edc9 in _internal_class_createInstanceFromZone 3: 0x344b5c9 in _class_createInstanceFromZone 4: 0x344b5ef in class_createInstance 5: 0x3326b57 in +[NSObject allocWithZone:] 6: 0x332583a in +[NSObject alloc] 7: 0x536ab67 in -[AVPlaybackQueue queueItemWasAddedNotification:] 8: 0x27f586 in _nsnote_callback 9: 0x328d165 in _CFXNotificationPostNotification 10: 0x2762ca in -[NSNotificationCenter postNotificationName:object:userInfo:] 11: 0x5354982 in -[AVQueue itemWasAdded:atIndex:] 12: 0x5354801 in -[AVQueue insertItem:atIndex:error:] 13: 0x53549d8 in -[AVQueue appendItem:error:] 14: 0x535c3be in -[AVController addNextFeederItemToQueue] 15: 0x535b06f in -[AVController checkQueueSpace] 16: 0x5359f46 in -[AVController setQueue:] 17: 0x535ac62 in -[AVController setQueueFeeder:withIndex:] 18: 0x30eee20 in -[MPAVController reloadFeederWithStartIndex:] 19: 0x30deed7 in -[MPMoviePlayerControllerNew _prepareToPlayWithStartIndex:] 20: 0x30dc686 in -[MPMoviePlayerControllerNew prepareToPlay] 21: 0x27f586 in _nsnote_callback 22: 0x328d165 in _CFXNotificationPostNotification 23: 0x2762ca in -[NSNotificationCenter postNotificationName:object:userInfo:] 24: 0x281238 in -[NSNotificationCenter postNotificationName:object:] 25: 0x31596d1 in -[MPMovie _determineMediaType] 26: 0x291b87 in __NSFireDelayedPerform 27: 0x32747dc in CFRunLoopRunSpecific 28: 0x32738a8 in CFRunLoopRunInMode 29: 0x3aaf89d in GSEventRunModal 30: 0x3aaf962 in GSEventRun 31: 0x52b372 in UIApplicationMain 32: 0x27be in main at /blablabla 33: 0x2735 in start
It sounds like you're calling release more than you are calling retain. Does the error message not contain a hex address at the end? If it does, follow these steps to hunt down the offending object: Navigate to Project->Edit Active Executable (or press Command-Option-X). Choose the arguments tab. Set the environmental variables as shown below: Run the program and repeat the steps needed to reproduce the error. Copy the hex address at the end of the error. Then, in the debugger console type this command: (gdb) info malloc-history <paste-address-here>. Examine the output to hunt down the offending object. P.S. Don't forget to disable the environmental variables when you're done.
maybe you call prepare to play more than once for the same movie and i think this is the problem and it exists to all ios prior to 4.3 i guess (not sure though) so just flag the movie if prepare to play was called once then don't recall it for the same file