Writing xlsx files on a Mac

SGaist

You may have found a bug in that library on macOS. What does the debugger tell you ?

JSher

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

SGaist

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 ?

JSher

@SGaist

Actually I was having trouble so I just cloned the source into my project for now so its the actual source files.

--James

SGaist

So did you check that you are passing correct data to that library ?

JSher

@SGaist

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

SGaist

Can you provide a minimal compilable example that reproduces this crash ?

JSher

@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

JSher

@SGaist

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

JonB

@JSher
If it really crashes on getenv( "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

@JonB It was an invalid access error. In doing research it does suggest that the environmental variable not being there can cause a crash.

@SGaist
I commented the line out and it works now:) That being said, I still do not see why that would cause a crash...should it just not return a null?

--James

JonB

@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.html

The getenv() function returns a pointer to the value in the
environment, or NULL 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.

JSher

@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-variabl

The 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

JonB

@JSher
Thank you for providing the reference. The answer there is:

The std::string class calls strlen when you use std::string(str), which will produce an access violation when passed a NULL 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 go std::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 type std::string you can tell the author he needs to change that. The crash will show up anywhere that there is no USERNAME environment variable, regardless of OS. My Linux & Windows happen to have one, perhaps MacOS doesn't.

All the best.

SGaist

Indeed it's USER on macOS.

Beside that, Qt provides qgetenv which can help avoid that kind of conversion issue.

JonB

@SGaist
The MacOS USER variable would explain.

The std::string(getenv("USERNAME")) crashing here is in third-party code, nothing to do with Qt, so qgetenv() is not going to help them fix :)