This project is read-only.




Can someone help me with my problem?
If I do:
string[] fileNames = new string[]{ "bla", "bla2"};
string zipFic = "bleble";
SevenZip.SevenZipCompressor szC = new SevenZip.SevenZipCompressor();szC.ArchiveFormat = OutArchiveFormat.SevenZip;szC.CompressionMode = CompressionMode.Create;szC.CompressionMethod = CompressionMethod.Default;szC.CompressionLevel = SevenZip.CompressionLevel.Ultra;szC.CompressFiles(zipFic, fileNames);

It works ok, but if I do first:
if (saveDialog1.ShowDialog() == DialogResult.OK)
zipFic = saveDialog1.FileName;
It stops on .CompressFiles and shows me a ContextSwitchDeadlock exception after around 1 min.

file attachments

Closed Aug 26, 2010 at 6:39 AM by markhor
Fixed. The solution is:(the most recent code is used from SVN)ArchiveUpdateCallback.cs, line 731. Comment out the lineGC.WaitForPendingFinalizers();Now everything should be fine.But wait! This is not all. You are using a synchronous call in your code:szC.CompressFiles(zipFic, fileNames);which blocks the UI thread until the compression is over. Starting from SevenZipSharp 0.64 (that is, built from SVN), you should use the following code instead:szC.BeginCompressFiles(zipFic, fileNames);This is an asynchronous call and the UI thread will continue to execute while files are being compressed.Good luck!


markhor wrote Aug 25, 2010 at 7:51 AM

Please also write SevenZipSharp version.

wrote Aug 25, 2010 at 12:27 PM

soltrac wrote Aug 25, 2010 at 12:29 PM

I've been looking this problem. See my project, it is very strange, at least, for me.

Plz, download from my website. I'm having problems attaching files (it stays forever trying to uploading it).

soltrac wrote Aug 25, 2010 at 12:30 PM

I've been looking this problem. See my attached project. It is strange, at least, for me.

markhor wrote Aug 26, 2010 at 4:38 AM

Downloaded the project

markhor wrote Aug 26, 2010 at 6:08 AM

I reproduced this issue.

The CLR has been unable to transition from COM context 0x3d7350 to COM context 0x3d74c0 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Trying to fix it.

wrote Aug 26, 2010 at 6:39 AM

wrote Feb 22, 2013 at 1:16 AM

wrote May 16, 2013 at 12:37 PM