Crash on opening

[kakohari]

Debian 10 x64 xCHM 1.23 (via apt/repo)

When opening attached file the following error is thrown: `ASSERT INFO: ../src/common/unichar.cpp(65): assert "Assert failure" failed in ToHi8bit(): character cannot be converted to single byte

BACKTRACE: [1] wxUniChar::ToHi8bit(unsigned int) [2] wxURI::Unescape(wxString const&) [3] wxFileSystem::URLToFileName(wxString const&) [4] wxFileSystem::OpenFile(wxString const&, int) [5] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler, wxEvent&) [6] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler) [7] wxEvtHandler::TryHereOnly(wxEvent&) [8] wxEvtHandler::ProcessEventLocally(wxEvent&) [9] wxEvtHandler::ProcessEvent(wxEvent&) [10] wxWindowBase::TryAfter(wxEvent&) [11] wxEvtHandler::SafelyProcessEvent(wxEvent&) [12] wxToolBarBase::OnLeftClick(int, bool) [13] g_closure_invoke [14] g_signal_emit_valist [15] g_signal_emit_by_name [16] g_closure_invoke [17] g_signal_emit_valist [18] g_signal_emit [19] g_closure_invoke [20] g_signal_emit_valist [21] g_signal_emit [22] g_closure_invoke [23] g_signal_emit_valist [24] g_signal_emit [25] gtk_propagate_event [26] gtk_main_do_event [27] g_main_context_dispatch [28] g_main_loop_run [29] gtk_main [30] wxGUIEventLoop::DoRun() [31] wxEventLoopBase::Run() [32] wxAppConsoleBase::MainLoop() [33] wxEntry(int&, wchar_t**) [34] __libc_start_main

` DATEV_Format_Pruefprogramm.zip

I am not quite sure if the file is corrupt itself - DATEV is known for shitty IT-business while being the german thing for payroll and taxes...

[rzvncj]

I'm not sure what's happening there, but the latest (released) xCHM version is 1.33, and I can open your .chm with no issues using it on Arch Linux (see attached screenshot). Maybe you could open an issue on Debian's bug tracker?

[rzvncj]

You may also be able to compile xCHM yourself, if you prefer - it should be relatively painless (please see the instructions on the project's main page). It's possible that wxWidgets also needs to be updated, which is slightly more involved, but not impossible. Let me know if you want to try this.

[kakohari]

Thanks for your quick reply, I will https://xkcd.com/303/ and post another reply here.

[PhoneixS]

I'm using 1.33 and have the same issue with one file, I've downloaded the file in the issue and it has opened correctly and now my file also open correctly (although it show wrong characters for ñ and tilde vowels).

Could it be that when it first open a file with a non ascii character it have the error but then it ignore it?

[rzvncj]

I'm using 1.33 and have the same issue with one file, I've downloaded the file in the issue and it has opened correctly and now my file also open correctly (although it show wrong characters for ñ and tilde vowels).

Could it be that when it first open a file with a non ascii character it have the error but then it ignore it?

No, if the same version of xCHM crashes the first time when opening a certain file, it should always crash on opening that file. Maybe you've upgraded your wxWidgets library in the meantime, or installed additional fonts on your machine?

[PhoneixS]

No, if the same version of xCHM crashes the first time when opening a certain file, it should always crash on opening that file. Maybe you've upgraded your wxWidgets library in the meantime, or installed additional fonts on your machine?

No, it was only minutes apart.

[PhoneixS]

Is there any cache or something similar?

[rzvncj]

What OS are you using? What wxWidgets version are you using? Is it built with Unicode support? Can you post the CHM file that crashed the application?

[rzvncj]

Is there any cache or something similar?

There is no cache.

[Kabingeran]

@rzvncj Doesn't open most books Ubuntu 22.04.4 https://nimb.ws/kDOj3ME Snap, 1.33

[rzvncj]

@rzvncj Doesn't open most books Ubuntu 22.04.4 https://nimb.ws/kDOj3ME Snap, 1.33

Does the regular package work?

[rzvncj]

From what I can tell looking around the issue appears to happen when wxWidgets tries to do an internal conversion (and fails) when an element of the path contains non-ASCII characters:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799302

But I've had no luck ever reproducing the issue on any system I've tried it on. I've just tried a Debian 12 virtual machine with xCHM 1.35, renamed chms to all non-ASCII names I could think of, and it works. Same on my Arch Linux machine.

In any case, I'd like to be able to reproduce this somewhere with an xCHM build from source. So far I don't have any reliable steps to reproduce.

[Kabingeran]

@rzvncj Is it possible to update snap version or regular package to 1.36? I'll try again.

[rzvncj]

@rzvncj Is it possible to update snap version to 1.36? I'll try again.

I don't control anything but the source code, I guess the snap team decides that (whoever they are). I just release new versions whenever there's enough new stuff to justify it and people pick them up if they want to.

[rzvncj]

@rzvncj Is it possible to update snap version or regular package to 1.36? I'll try again.

But can you tell us more about your environment? Are the chm documents you're trying to open inside a path that contains non-ASCII characters? Are the files' names non-ASCII? Anything at all that could help me trigger this on my development machine?

So far trying to rename chm files to weird things has not done the trick for me at all.

[Kabingeran]

@rzvncj I think you are in a situation where you will have to take charge of building the deb package yourself. Your product has not been updated for a long time.

[rzvncj]

@rzvncj I think you are in a situation where you will have to take charge of building the deb package yourself. Your product has not been updated for a long time.

I wish I had time to do that, unfortunately this is just a passion project, I'm grateful for the help of all the maintainers out there who thought the distro work is worth doing.

[Kabingeran]

@rzvncj Then pass the project on to your friends

[rzvncj]

@rzvncj Then pass the project on to your friends

Well, the beauty of GPL is that anyone thinking they can do a better job is free to fork the project as long as the conditions of the license are met. :)

[Kabingeran]

@rzvncj I was talking about reputation and delegating responsibility, not code.

[rzvncj]

@rzvncj I was talking about reputation and delegating responsibility, not code.

Noted. I think we may have strayed quite a bit from the topic of this issue though.

Returning to the topic, details on how somebody else might be able to reproduce this are appreciated (e.g. relevant environment variables, complete list of libraries xCHM links against, successful attempts to reproduce this on a different OS, etc.).

[Kabingeran]

You are marked to support Ubuntu. You can get the Ubuntu Desktop image from the official website and install the snap package from the app store.

[rzvncj]

You are marked to support Ubuntu. You can get the Ubuntu Desktop image from the official website and install the snap package from the app store.

The Ubuntu package is supported by the package maintainers. The main project page states:

I am no longer providing Mac and Windows binaries, just the source code. Some Linux distributions already provide binaries (Debian, Arch, Gentoo, Ubuntu, etc.),

Expecting upstream FLOSS developers to just try to duplicate the full environment of a bug reporter, or pick up maintenance of distro packages is just not realistic. Sometimes it happens, but it is by no means an obligation.

In fact, with FLOSS projects any bug reporter is a potential developer - patches addressing problems are appreciated even more than bug reports!

[Kabingeran]

As I understand it, the problem occurs when the file name contains Cyrillic. As a result, the file does not open. But I could be wrong.

[rzvncj]

As I understand it, the problem occurs when the file name contains Cyrillic. As a result, the file does not open. But I could be wrong.

Sure, that's what I understood too from the Debian bug link (wasn't the case with the original post though!) but here's what's happening for me (nothing, it works perfectly):

Screencast from 2024-04-02 20-25-30.webm

So there must be something else involved. Maybe a certain wxWidgets version. Maybe the contents of an evironment variable such as LANG.

[Kabingeran]

I tested on version 1.33

[rzvncj]

And here's what happening to me (again, nothing, it all works perfectly) with the original file posted when this issue was opened:

Screencast from 2024-04-02 20-31-44.webm

Now, I know "it works on my machine" is not a valid resolution, but clearly something more subtle is happening here, and until it's clear to us how to reliably reproduce the issue we can't make any serious claim that it has been fixed either.

[rzvncj]

I tested on version 1.33

Shouldn't matter, that backtrace looks like a wxWidgets thing, and no code handling that path has been changed since 1.33. But I've checked out the 1.33 tag and tried just in case. Again nothing crashed for me:

Screencast from 2024-04-02 20-38-55.webm

[rzvncj]

Also, FWIW I've installed snap in a Debian VM I already have and there doesn't appear to be any xchm snap package at all:

https://snapcraft.io/search?q=xchm

Does Ubuntu use a different version of snap, is the package called something else, or?...

[Kabingeran]

Sorry, I stopped at the kchmviewer project

[Kabingeran]

https://i.postimg.cc/9f8TGY6w/2024-04-02-20-52-08.png

[rzvncj]

OK, I've started a live version of Ubuntu, set snapd up inside it, installed xCHM, noticed it linked against wxWidgets 3.0. I've then downloaded wxWidgets 3.0 locally and built xCHM from source against it.

The problem is wxWidgets 3.0. My Arch Linux is using 3.2 (which is the latest stable version), and that turns out to be why I could never reproduce this.

So we can finally put this thing to rest: as binary package maintainers will move away from wxWidgets 3.0, this problem will automatically be solved. It's not an xCHM issue.

[Kabingeran]

I needed to open a file urgently. I apologize, I didn't have time to research the problem.