View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008348 | MMW v4 | Synchronization | public | 2011-09-07 23:25 | 2011-09-18 19:52 |
| Reporter | Assigned To | ||||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0008348: iPad 2 sync 'thread creation error - not enough storage to process this request' | ||||
| Description | Syncing with the iPad 2 brings about a "Thread creation error" and the sync terminates before it is completed. | ||||
| Steps To Reproduce | 1. Start with cleared iPad (no audio tracks) 2. Select a large amount of files via playlists to sync (3000 audio files here) 3. Auto-conversion rules are incompatible -> mp3 (v5) 4. Initiate sync. After about 100 files are sync'ed, 'thread creation error - not enough storage to process this request' pops up from time to time 5. The sync is terminated around file 300 or so 6. No playlists are copied to the device | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=59768 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1433 | ||||
|
|
Log file is attached |
|
|
The problem is in failed JPEG conversions. |
|
|
This regression (failed JPEG conversion) has been introduced in build 1425 while fixing 0008255 (SVN revision 12524). I created some Dunit tests to preserve problems like this. Aside from the failed artwork conversion there was really a huge memory leak (the reason for the thread creation error). Fixed in build 1429. |
|
|
Confirmed on forum |
|
|
I'm still having an issue where MM crashes while I sync with an iPad 2. I've uploaded another log, but hard to say if there's anything useful in it, it looks like it just cuts off as MM closes during the sync. http://www.4shared.com/file/23F8Ajdl/ipadSTEVE-PC.html |
|
|
It looks that there still exists a memory leak although I haven't found any so far (but I don't have iPad). Was your memory utilization very high at the moment? I suspect that there could be a memory leak in decode/encode plugin rather than in the main app. Attach please your device profile so that we could see your exact device settings. |
|
|
I just tried the sync again. It's hard to say, I watched the memory usage in the task manager but when MM crashed it was only at about 150 MB. During the sync process the memory usage had gone higher than that (up to 250 MB or so) but come back down. |
|
|
Jiri also couldn't reproduce the issue with iPad. Stephen, could you please 1. Download process explorer: http://technet.microsoft.com/en-us/sysinternals/bb896653 2. Run it together with MM and start syncing 3. Right-click MediaMonkey.exe in the Process Explorer and select [Performance] tab. Watch 'Virtual memory' and 'Handles' boxes, does it grow? And also attach your device profile (MMDC file) so that we could see your device settings. |
|
|
http://www.4shared.com/file/0aJGT_6V/iPadsyncCrash.html I uploaded a video of the sync with Process Explorer open, the Virtual Memory does grow up to the point of the crash. It crashes in the last 30 seconds of the video. The sync did get much farther than usual this time, usually the crash has been happening after copying around 500 tracks. |
|
|
Ok, the video shows that it's the 'Virtual Size' of 'Virtual Memory' that causes problem - it's 1.5GB right on start and so it very quickly approaches 2GB limit. I tested various scenarios of start-up on my PC, all results in MB: MM4 debug: Default: 770 With UPnP server: 950 No plugins: 356 Specific plugins: d_WMDM: 50 d_iPod: 40 d_iPhone: 180 ! MM3 debug: Default: 445 No plugins: 246 d_iPhone: 85 This raises a couple of questions: 1. Why starting a UPnP server consumes so much memory? 2. Why the same dll (d_iPhone) consumes 100MB more memory in MM4 than in MM3? |
|
|
The problem is in our default callstack (16MB), which was just 1MB previously. Assigning to Petr to decrease it (unless there's any reason for this, in which case we must eliminate the reason). |
|
|
Fixed in 1433 (fixed stack size to 1024) |
|
|
The callstack size was still 16MB in the project (dproj) file (i.e. in our internal build). Fixed (doesn't affect public builds). |
|
|
verified 1433 |
