Mono issues on ubuntu (pdf/equations)

Aspose.Cells Product Family
15

Hi William,


I am afraid, we haven’t yet received any updates regarding the tickets attached to this thread. We have requested the development team to share their valuable feedback on both tickets, and we will post here as soon as some news comes in.

We are sorry for the inconvenience caused.
16

Hello Babar, do you have any valuable feedback from the development team that you have received over the past week since your last post here?

17

Hi William,


I am afraid, we haven’t yet received any updates regarding the both tickets attached to this thread. I have now elevated the priority of the tickets to the highest value possible, and have recorded notes stating the severity of the problems. We will shortly respond back with more details in this regard.

Please accept our apologies for the inconvenience caused.
18

Thank you, Babar. Please keep me updated.

19

Hi William,


We have got updates regarding the tickets attached to this thread. Please check the comments as follow,

  • CELLSNET-42528: Unfortunately, the current implementation of Aspose.Cells APIs do not support math equations as they are in your provided sample (json-test-1.xlsx). This is actually a new feature request that we may consider implementing in the future releases, but we first need to analyze it properly in order to bring it on our road map of Aspose.Cells APIs. Therefore we can not commit any timelines at the moment although the ticket is still open for further investigation.
  • CELLSNET-42539: The exception stated in this ticket is due to the reason that Aspose.Cells APIs converts the spreadsheets, charts and shapes to EMF format, and inject these EMF images into the resultant PDF. On the other hand, Mono does not support creation of EMF files as we have researched it. You can workaround this situation by specifying the ImageFormat for the object of PdfSaveOptions while converting the spreadsheets to PDF format. Please check the below provided code snippet that we have tested against Mono versions 3.2.6 & 3.2.8 with MonoDevelop 4.0.12 and the latest version of Aspose.Cells for .NET 8.0.1.1.

C#

var file = “/home/babar/Downloads/Tear_Sheet_values.xlsx”;
Workbook book = new Workbook(file);
Console.WriteLine(“Spreadsheet Loaded!”);

PdfSaveOptions pdfSaveOptions = new PdfSaveOptions();
pdfSaveOptions.ImageType = System.Drawing.Imaging.ImageFormat.Png;
book.Save(“/home/babar/Downloads/output.pdf”, pdfSaveOptions);

Console.WriteLine(“Spreadsheet Converted!”);


Please note, the above code snippet requires reference of System.Drawing namespace in the project, whereas the aforesaid namespace is present in libgdiplus library that installs automatically with the installation of MonoDevelop application. In case you do not find this library in your environment, you can get it from the below provided link.
http://download.mono-project.com/sources/libgdiplus

If you wish to make sure that Mono does not provide support for EMF creation on your end, please give the below provided code snippet a try on your end. The probable outcome is either a GDI+ exception or a zero sized EMF file.

C#
System.IO.FileStream fs = new System.IO.FileStream(@"/home/babar/Downloads/test.emf", System.IO.FileMode.Create);
System.Drawing.Bitmap dummyBitmap = null; System.Drawing.Graphics dummyGfx = null; IntPtr hdc = IntPtr.Zero; System.Drawing.Imaging.Metafile metafile = null;
try { // Below code is needed to create a .NET Graphics object that can record a metafile. dummyBitmap = new System.Drawing.Bitmap(1, 1); dummyGfx = System.Drawing.Graphics.FromImage(dummyBitmap);
hdc = dummyGfx.GetHdc();
Console.WriteLine(hdc);

int mWidth = 200; int mHeight = 200;
metafile = new System.Drawing.Imaging.Metafile(fs, hdc, new System.Drawing.RectangleF(0, 0, mWidth, mHeight), System.Drawing.Imaging.MetafileFrameUnit.Pixel, System.Drawing.Imaging.EmfType.EmfPlusDual);
System.Drawing.Graphics mGr = System.Drawing.Graphics.FromImage(metafile); // Use FillRectangle instead of Clear because Clear does nto seem to work for metafiles. // FillRectangle also establishes good page boundaries for the metafile.
Console.WriteLine(mGr.VisibleClipBounds);
mGr.FillRectangle(new System.Drawing.SolidBrush(Color.Empty), 0, 0, mWidth, mHeight);
//Draws mGr.DrawString(" Test draw text!", new System.Drawing.Font("Arail", 8), new System.Drawing.SolidBrush(System.Drawing.Color.Red), 50, 10); mGr.DrawLine(new System.Drawing.Pen(Color.Blue, 3), 0, 100, 200, 100); mGr.FillRectangle(new System.Drawing.SolidBrush(Color.FromArgb(100, 255, 0, 0)), 50, 50, 100, 100); mGr.Dispose(); } finally { if (metafile != null) metafile.Dispose(); if (hdc != IntPtr.Zero) dummyGfx.ReleaseHdc(hdc); if (dummyGfx != null) dummyGfx.Dispose(); if (dummyBitmap != null) dummyBitmap.Dispose(); }

Please feel free to write back in case you have questions for us.
20

Hello, Babar. Thank you for your reply.


I would like to report that the latest version of Aspose.Cells that you gave me (version 8.0.1.1) crashes mono as soon as Aspose.Cells.dll is loaded. I am still using the same environment (mono 3.2.7, ubuntu 12.04). The old version (version 8.0.0.1) only crashed mono when we tried to save a pdf that had charts in it.

I tried to debug this as far as I could, but the crash seemed deep inside of the mono code. I used gdb to help, so maybe this will give you a clue when the crash occurs:

* Assertion: should not be reached at tramp-amd64.c:405

Program received signal SIGABRT, Aborted.
0x00007ffff712b425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) backtrace
#0 0x00007ffff712b425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff712eb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000062f2cd in monoeg_g_logv (log_domain=, log_level=G_LOG_LEVEL_ERROR, format=, args=) at goutput.c:175
#3 0x000000000062f406 in monoeg_assertion_message (format=) at goutput.c:195
#4 0x000000000050514d in stack_unaligned (tramp_type=) at tramp-amd64.c:405
#5 0x0000000040003d49 in ?? ()
#6 0x00007ffff658ed60 in ?? ()
#7 0x00000000400c0774 in ?? ()
#8 0x00000000400c0755 in ?? ()
#9 0x00000000400c074c in ?? ()
#10 0x00000000015e8660 in ?? ()
#11 0x00007ffff658f068 in ?? ()
#12 0x0100000000a3b1a0 in ?? ()
#13 0x00007ffff658f068 in ?? ()
#14 0x00007ffff658f000 in ?? ()
#15 0x00000000015e8660 in ?? ()
#16 0x00007ffff658ed38 in ?? ()
#17 0x00007ffff658f000 in ?? ()
#18 0x00007ffff658f000 in ?? ()
#19 0x00007fffed6d8240 in ?? ()
#20 0x00007fffed6d8240 in ?? ()
#21 0x00000000400c0376 in ?? ()
#22 0x00007ffff658efa0 in ?? ()
#23 0x00000000005ae2dd in mono_object_isinst (obj=0x7fffffffd3e8, klass=0x7ffff7fde780) at object.c:5256
#24 0x00000000400223a3 in ?? ()
#25 0x0000000000a3b1a0 in ?? ()
#26 0x00000000400ba0c0 in ?? ()
#27 0x00007fffffffd1a8 in ?? ()
#28 0x00007ffff7fde780 in ?? ()
#29 0x00007ffff658ed38 in ?? ()
#30 0x00007ffff658f000 in ?? ()
#31 0x00007fffffffd268 in ?? ()
#32 0x0000000040142b80 in ?? ()
#33 0x00007ffff658f000 in ?? ()
#34 0x00007ffff658ed38 in ?? ()
#35 0x0000000000000000 in ?? ()

This crash happens every time.

The first code that is run that accesses Aspose.Cells that causes the dll to be loaded is:
Aspose.Cells.License license = new Aspose.Cells.License();
license.SetLicense(“Aspose.Cells.lic”);

The exact commit we are using to build mono is: GitHub - mono/mono at 1b62dca6cc70df2a017947666619276c84050121

Since this crashes mono every single time when we start up our process, it makes Aspose.Cells completely unusable. Please help me with a fix.

21

Hi William,


We are sorry to know that the workaround shared in our previous response didn’t help in your environment. Could you please simply switch back to Aspose.Cells for .NET 8.0.0.1 and see if you can generate PDF using the code snippet shared here?

Moreover, we suspect that there are problems in your version of the mono installation, as we haven’t encountered such problem when using later versions of the mono. Also we were unable to find mono 3.2.7 for our testing, because due to some unknown reasons this particular version is unavailable for download. Please check the below link and attached snapshot for your kind reference.
Index of /sources/mono

22

Hello Babar,


I tried using version 8.0.0.1 and the good news is that mono does not crash when the process starts up. The bad news is that pdf generation crashes mono instead.

You can download the exact build we use for mono from: https://github.com/mono/mono/archive/1b62dca6cc70df2a017947666619276c84050121.zip

23

Hi William,


Thank you for the link. I have started downloading your exact mono build, though I still suspect that the problem isn’t Aspose.Cells API in crashing the mono if you use the updated code with any of the Aspose.Cells versions; 8.0.0.1 & 8.0.1.3. I have now verified the results with mono 3.4.0 while using both Aspose.Cells versions therefore I would strongly recommend you to upgrade your mono installation to any recent releases. It would be more appropriate that you should freshly install mono on a new VM for testing purposes. I will do the same on my end to test your shared build.

Keep us posted with updates.
24

Hello, Babar. So far we haven’t been able to find anything on our side about the mono installation. Has your investigation uncovered anything? If it was our mono installation, how come version 8.0.0.1 worked but 8.0.1.1 crashed immediately?

25

Hi William,


First of all, please accept my apology for a bit delayed response.

Unfortunately, we are unable to figure out the problem cause nor we could establish the recent behavior to be a bug the on the part of Aspose.Cells APIs. Reason being when we installed the mono 3.2.7 on our end, and tested the updated code snippet against the latest version of Aspose.Cells for .NET 8.0.1.3, we are unable to replicate the NullRefernceException as stated here. Instead we are getting “Program received signal SIGABRT, Aborted.” with random stack traces. I have searched over the internet to get any valid justification for this error, and have noticed that people are getting such exceptions due to different reasons (buffer overflow, incorrect pointers, missing assemblies etc) therefore the cause of this exception in this particular scenario is still unclear to us. The ticket (CELLSNET-42539) in this reference is still open in our bug tracking system, and we will look further into this matter to find a solution (if possible).

Just wondering, have you given a try to any recent versions of mono (3.2.8 or 3.4.0) as requested in my previous post. Please note, Aspose.Cells for .NET versions 8.0.0.1, 8.0.1.1 & 8.0.1.3 exhibit desired results when complied with mono 3.2.6, 3.2.8 & 3.4.0.

26

Hello, Babar, I work with William and have been looking into this issue on our side.


I have tried running with mono 3.2.6 and 3.4.0 with the 8.0.1.3 version you provided and I am still seeing similar SIGABRT issues.

Would it be possible to create and send me a C# project that contains the correct version of Aspose.Cells and a test xlsx file that works on your test server that I can use on our test servers So I know the code I am using to test our Mono installation works for you. This would help with debugging our problems.

Thanks for your help.
27

Hi there,


Please find the attachment for the Mono project in an archive. Please note, the archive also contains the the latest official build of Aspose.Cells for .NET 8.0.1 that I have been using for testing purposes. Also attached a few snapshots showing the Mono version that worked fine on my end. I have always used your provided spreadsheet for my testing, so you can get it from here.

Regarding the environment, I would suggest you to setup a new VM by installing everything fresh. Doing so will minimize the chances of conflict as well as you will be able to pin point the problem, if any occur. Moreover, it is suggested that you should install the Mono/MonoDevelop from Ubuntu Software Center or from Git, this will insure the integrity of your installation package.

28

Hi,


Thanks for the project.

I have matched your mono and monodevelop versions on a fresh Ubuntu install and if I run the project in monodevelop with debugging everything works, If I run in monodevelop without debugging it wont work.

I can run via the command line, monodevelop any way as long as it runs with the debugging option “–debugger-agent=transport=dt_socket,address=127.0.0.1:10000”, If it runs without that option It will fail with the SIGABRT errors.

If your VM does work without the debugging option, Is there any way I could get a copy/access to it to look at it in greater detail.

Thanks
29

Hi there,


Thank you for writing back, and good to know that we have moved passed the previous problem.

Regarding the SIGABRT errors, unfortunately, we are not getting these errors. Instead we have observed SIGSEGV error while running the project without debugging. Moreover, we have noticed that the problem tends to occur when some method/class of Aspose.Cells is used in the project. Based on aforesaid observations we have logged an investigative ticket under Id CELLSNET-42635, and requested the development team to look further into this matter. As soon as we receive any updates in this regard, we will let you know here.

Stack trace for your future reference is as follow,

[New LWP 4525]
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/i386-linux-gnu/libthread_db.so.1”.
0xb7777424 in __kernel_vsyscall ()
Id Target Id Frame
2 Thread 0xb715fb40 (LWP 4525) “mono” 0xb7777424 in __kernel_vsyscall ()
* 1 Thread 0xb753f740 (LWP 4524) “mono” 0xb7777424 in __kernel_vsyscall ()

Thread 2 (Thread 0xb715fb40 (LWP 4525)):
#0 0xb7777424 in __kernel_vsyscall ()
#1 0xb76fd135 in sem_wait@@GLIBC_2.1 () at …/nptl/sysdeps/unix/sysv/linux/i386/i686/…/i486/sem_wait.S:79
#2 0x0827f8d6 in mono_sem_wait (sem=sem@entry=0x83c5058 <finalizer_sem>, alertable=alertable@entry=1) at mono-semaphore.c:119
#3 0x081f5573 in finalizer_thread (unused=unused@entry=0x0) at gc.c:1073
#4 0x081d6fd0 in start_wrapper_internal (data=0x87525b8) at threads.c:643
#5 start_wrapper (data=0x87525b8) at threads.c:688
#6 0x0827393f in thread_start_routine (args=args@entry=0x87017c4) at wthreads.c:294
#7 0x08283e53 in inner_start_thread (arg=0x87524c0) at mono-threads-posix.c:49
#8 0xb76f6f70 in start_thread (arg=0xb715fb40) at pthread_create.c:312
#9 0xb762d70e in clone () at …/sysdeps/unix/sysv/linux/i386/clone.S:129

Thread 1 (Thread 0xb753f740 (LWP 4524)):
#0 0xb7777424 in __kernel_vsyscall ()
#1 0xb76fecdb in waitpid () at …/sysdeps/unix/syscall-template.S:81
#2 0x08105bf1 in mono_handle_native_sigsegv (signal=signal@entry=11, ctx=ctx@entry=0xb7765b6c) at mini-exceptions.c:2299
#3 0x08153274 in mono_arch_handle_altstack_exception (sigctx=sigctx@entry=0xb7765b6c, fault_addr=0xbf755ebc, stack_ovf=stack_ovf@entry=0) at exceptions-x86.c:1163
#4 0x0806a20b in mono_sigsegv_signal_handler (_dummy=7, info=0xb7765aec, context=0xb7765b6c) at mini.c:6769
#5
#6 mono_arch_handle_altstack_exception (sigctx=sigctx@entry=0xb7765d0c, fault_addr=0x0, stack_ovf=stack_ovf@entry=0) at exceptions-x86.c:1184
#7 0x0806a20b in mono_sigsegv_signal_handler (_dummy=11, info=0xb7765c8c, context=0xb7765d0c) at mini.c:6769
#8
#9 0xb7236175 in ?? ()
#10 0x00000000 in ?? ()

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

bash: line 1: 4524 Aborted (core dumped) /usr/bin/mono --debug “/home/babar/TestConsole/TestConsole/bin/Debug/TestConsole.exe”
30

Hello Babar, have you heard back from your development team about this issue?


Thank you for your support,
Bill
31

Hi Bill,


I am afraid, we haven’t yet received any updates from the development end regarding the last logged ticket. We have recorded a note for the concerned development team member to share the insight of the presented problem. As soon as some news comes in, we will post here for your kind reference.
32

Babar, please share the latest news on this ticket. We are still hoping for a fix soon so that we can begin using pdf generation without having to turn on debugging.

33

Hi Bill,


Thank you for your patience with us.

We have sorted out the problem previously logged as CELLSNET-42635. Please find the attachment for the latest version of Aspose.Cells for .NET 8.0.2.1 (.NET 2.0) assembly in an archive having the fix. We have tested on our end that while using the latest assembly, we are able to run the project without debugging, and have generated the desired results. Please note, we have performed the aforesaid test on mono 3.2.8.

Please go ahead and give the latest version a try on your end. In case you face any difficulty, please feel free to write back.
34

The issues you have found earlier (filed as CELLSNET-42635) have been fixed in this update.

This message was posted using Notification2Forum from Downloads module by Aspose Notifier.