Unsolved Writing xlsx files on a Mac
-
Hello,
I am using SimpleXlsxWriter and it functions fine on windows. When I move my code to a mac it compiles fine but crashes on SimpleXlsx::CWorkbook book;
Anyone have this experience or can suggest another xlsx writer?
Thanks,
--James -
Hi,
Where does that library come from ?
-
-
You may have found a bug in that library on macOS. What does the debugger tell you ?
-
I cannot get it to tell me anything, it just crashes. I find the QT Creator debugger not as good as the VS one but I dont not have VS on the Mac... Any suggestions as to how I get more information from the debugger, remember I am new to C++:) I tried adding a break point and stepping in etc..it brought me to string line 891:
_LIBCPP_INLINE_VISIBILITY basic_string& operator=(const value_type* __s) {return assign(__s);}
Once there I can step no further.
Thanks,
--James -
Qt Creator has no debugger, it uses the one provided by the build tools of the platform.
Did you build that library in debug mode ?
-
Actually I was having trouble so I just cloned the source into my project for now so its the actual source files.
--James
-
So did you check that you are passing correct data to that library ?
-
As far as I can tell I am. It works fine on windows under both QT Creator with mingw and Visual Studio with vs2017
EDIT: That entry does not take data. It just create a blank workbook with a default constructor.
--James
-
Can you provide a minimal compilable example that reproduces this crash ?
-
@SGaist
Working on it now. Is there something I can do to get more information on the mac? Trying to see where it fails in the constructor....Thanks,
--James -
So I created a GUI project in QTCreator. I added a pushbutton. I imported the source code for SimpleXlsx (not a lib).
When the button is pushed I simply create a workbook using CWorkbook book and it crashes.
Here is the mainwindows.cpp:
#include "mainwindow.h" #include "ui_mainwindow.h" #include "Xlsx/Workbook.h" MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent) , ui(new UI::MainWindow) { ui->setupUi(this); } MainWindow::~MainWindow() { delete ui; } void MainWindow::on_pushButton_clicked() { SimpleXlsx::CWorkbook book; }
According to the mac stack it appears to crash in SimpleXlsxDef.h:87 from Workbook.cpp:108 which would suggest it may be a permission issue?
EDIT: forgot to write the line I think it crashes on: m_UserName = getenv( "USERNAME" );
Thanks,
--James -
@JSher
If it really crashes ongetenv( "USERNAME" )
, why would you think that "a permission issue" (whatever you mean by that)?getenv()
is just a C runtime call to search the process's environment variables (it is OK if it does not find the specified name); if that really "crashes" it would imply it is (somehow) not pointing to a valid environment to search.FWIW, this library does not have any need of Qt. You could set up a tiny C++ program outside of anything Qt to see if you have a problem there or not.
-
-
@JSher said in Writing xlsx files on a Mac:
@JonB It was an invalid access error. In doing research it does suggest that the environmental variable not being there can cause a crash.
Where in the world do you get that from about the crash, I'd like to read?
getenv("nonexistentname")
has always returned NULL since the 1970s, else you could never trust to ask for an environment variable which might not exist, which would break millions of programs. http://man7.org/linux/man-pages/man3/getenv.3.htmlThe
getenv()
function returns a pointer to the value in the
environment, orNULL
if there is no match.That being said, I still do not see why that would cause a crash...should it just not return a null?
As I said, the only way it could crash is if the environment being searched is invalid, not that the named variable cannot be found there. Why that is happening to you on MacOS I cannot say, it would worry me.
-
@JonB Where in the world do you get that from about the crash, I'd like to read? getenv("nonexistentname") has always returned NULL since the 1970s, else you could never trust to ask for an environment variable which might not exist, which would break millions of programs. http://man7.org/linux/man-pages/man3/getenv.3.html
wow relax:) I did not explain myself well enough and the comment was in relation to THIS problem where they use std::string in the library and this post: https://stackoverflow.com/questions/5232109/access-violation-exception-while-using-getenv-to-retrieve-an-environment-variabl
SO
SimpleXlsxDef line 87
UniString & operator=( const char * other ) { m_string = other; //line 87 m_wstring = std::wstring( m_string.begin(), m_string.end() ); return * this; }
then
std::string m_string; //line 113
again refer to this post:
https://stackoverflow.com/questions/5232109/access-violation-exception-while-using-getenv-to-retrieve-an-environment-variablThe error on mac I am getting is access violation.
This is what I was referring to. So when then environmental error is not there and returns null you cant use a std::string.
I was more or less talking outloud as I was trying to work the problem.
Remember some people, like me, are new to C++ and to compound that, I do not use Macs
Thanks for pointing me in the right direction if I am in fact in the right direction:)
--James -
@JSher
Thank you for providing the reference. The answer there is:The
std::string
class callsstrlen
when you usestd::string(str)
, which will produce an access violation when passed aNULL
string.So it has nothing to do with "it does suggest that the environmental variable not being there can cause a crash [in
getenv()
]", it's just to do with you must not gostd::string(NULL)
from anything, which is totally different matter.Now that I understand this, where you say the code goes
crashing in Workbook.cpp on line 108 m_UserName = getenv( "USERNAME" );
if
m_UserName
is of typestd::string
you can tell the author he needs to change that. The crash will show up anywhere that there is noUSERNAME
environment variable, regardless of OS. My Linux & Windows happen to have one, perhaps MacOS doesn't.All the best.
-
Indeed it's
USER
on macOS.Beside that, Qt provides qgetenv which can help avoid that kind of conversion issue.
-
@SGaist
The MacOSUSER
variable would explain.The
std::string(getenv("USERNAME"))
crashing here is in third-party code, nothing to do with Qt, soqgetenv()
is not going to help them fix :)