Hi!
I am experimenting thread freeze while saving PresentationEx (see ThreadJob1) or exceptions while modifying Shape (see ThreadJob2) when using aspose.slides in multithreading environment :
public void ThreadJob1()
{
// saving pptx
PresentationEx presex = new PresentationEx(path + filename);
for (int i = 0; i < count; i++)
{
MemoryStream stream = new MemoryStream();
presex.Save(stream, SaveFormat.Pptx);
System.Diagnostics.Trace.WriteLine(Thread.CurrentThread.ManagedThreadId + “:” + i);
}
}
public void ThreadJob2()
{
// modifiy ppt
Presentation pres = new Presentation(path + filename);
for (int i = 0; i < count; i++)
{
foreach (Shape shape in pres.Slides[0].Shapes)
{
shape.X += 10;
shape.Y += 10;
Thread.Sleep(0);
}
System.Diagnostics.Trace.WriteLine(Thread.CurrentThread.ManagedThreadId + “:” + i);
}
}
Please see attached code
This is very important : Is Aspose.Slides Really Threadsafe ?
Thanks
Hi Pascal,
Ok, here are the presentations I used.
With pptx, crash (ThreadJob3, see under) or freeze (ThreadJob1, same as yesterday) will append quickly : several hundreds of iterations with 16 threads on my core i7 CPU.
With ppt, is it much more unfrequent maybe because ppt api is faster than pptx.
Please note : All that append outside debugger.
Here the function for multislide presentation :
public void ThreadJob3()
{
// modifiy pptx
PresentationEx presex = new PresentationEx(path + filename);
for (int i = 0; i < count; i++)
{
foreach (SlideEx slide in presex.Slides)
{
foreach (ShapeEx shape in slide.Shapes)
{
// reading seems to be ok
float x = shape.X;
float y = shape.Y;
// modifying leads to exception
shape.X = x + 10;
shape.Y = y + 10;
}
}
System.Diagnostics.Trace.WriteLine(Thread.CurrentThread.ManagedThreadId + “:” + i);
}
}
Thanks
Hi,
Thanks for your response.
By “freezing” I mean that while the program is still running and of course before loops are finished, CPU is at 0%.
Here is a screenshot of debugger after attaching it to the process (ThreadJob1Stucked.jpg).
I also took screenshots after program crash while running the ThreadJob3 scenario:
ThreadJob3Exception01.jpg, ThreadJob3Exception02.jpg (Win7 x64, core i3; 12Go)
and ThreadJob3Exception02WinXP.jpg (Win XP 32 bits core 2 duo 4Go).
Hi,
Hi !
Thanks for considering this issue.
This is very important fior our project, we are currently blocked in the development as multithreading and scalability is required.
If you want to reproduce these bugs, please launch the exe outside the debugger, monitor the activity with DebugView and… wait a few minutes.
Issue has occured on every machine and OS : Core duo, i3, i7…
Thanks for your attention.
Hi,
Hi
week 51/2012 has gone…
Is there any news about these issues ?
Shall we consider that Aspose.Slides is definitively NOT threadsafe ?
Regards
Hi,
Mudassir:Hi,Please accept my sincere apologies for the inconvenience on your end. I have verified from our issue tracking system and like to share that owing to pending issues and product releases the issue have not been resolved yet. In fact it has been moved to Week 05/2013 for investigation. I am sorry for your inconvenience but will really appreciate if you may please hold on for the requested time and our development team may carry on their investigation. I will add request in our issue tracking system as well for as soon as possible investigation of the issue.Many Thanks,
Hello,
Ok, we are now Week 7... Anything new ?
Hi,
Hi,
Hello
I have made more stressing tests and you/we have a real problem of concurrent access somewhere near the calls to System.Drawing.dll.
Please note I am talking about the “save” issue, ie saving a Presentation or PresentationEx (ThreadJob0 ot ThreadJob1 in the attached source code).
Your development team should have seen it.
- Sometimes all threads hang, sometimes all but one and memory usage grows like crazy, sometimes an exception is thrown…
- It seems it happens much more often on a fast desktop corei7 than on the “old” laptop core2.
- It happens on a VM (on the same computer), provided that the VM uses more than one processor.
If you want to reproduce this issue (and I am sure you will) please note :
- Use a high speed CPU
- Use more threads than available processors/cores
- Use parameters like they are in the source code, just change the path.
- Save to pdf
- And Please let the test program run at least one minute or two.
Unfortunately, as you know, the customer’s servers are generally high power machines and we have to be robust enough…
Thanks for reading.
Hi,
Hi, thanks for your tests and your answer.
Here are some news :
I have tested on different VM :
- Win7 32 fr
- Win7 64 fr
- Win7 64 en
- Win8 32 fr
The issue occurred only in 64bit version and does not seem to be language related…
Here is what I discovered :
If I generate in “x86”, it’s ok everywhere
If I generate in “x64” or “Any CPU”, it fails on x64 platforms.
Unfortunately that’s a half good new because we lose the benefit of memory size and as you know sometimes Aspose.Slide is very very memory consuming…
Another thing I discovered is that I am using Microsoft Visual Studio 2010 Professional SP1 (Version 10.0.40219.1 SP1Rel), and it seems that you are using VS 2008.
So I generated on another computer with VS2005… and it still crash the same way
Then I tested with your exe and… still crash too!
Have you or your team ever heard about such problem ?
Is there something I am wrong with ?
What can I do to check compilation/installation process? (Of course I read the doc)
Thanks in advance
Regards
Hi,
Thanks for your further investigation. I like to share that our development team is also observing the issue and I have updated the issue status with new information shared by you.
Thanks for your test with VS2010
The exe in your zip is “x86” so it run ok here.
After regenerate in “AnyCPU” and when lauched in a command prompt window it crashes like the others as you can see in the log attached.
Regards.
NB:
“Le paramètre n’est pas valide” is “invalid parameter”
“Tentative de lecture ou d’écriture de mémoire protégée. Cela indique souvent qu’une autre mémoire est endommagée.” is “Attempted to read or write protected memory. This is often an indication that other memory is corrupt.”
Hi,
Hello,
This is the same application I sent you and you sent me back yesterday, compiled for .NET 4.0.
Regards