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.
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.
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.
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?
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.
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.
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.
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.
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”
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.
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.
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.