Issues/Bugs

[am2del]

A brief overview - INDEX:

--> Issue/Bug #1 - Crash when opening Kanji-info boxes. --> Issue/Bug #2 - Crash when hitting "cancel" upon browsing for importing user data. --> Issue/Bug #3 - Minimize to tray, no icon and impossible to restore.

-- Issue/Bug #1 --

When trying to open the Kanji dialog info box on build v. 0.0.2, v. 0.0.3 and GIT, zKanji will inevidibly crash. The popup boxes on hover with info works fine though, it's the dialog one which stays on-top and contains the stroke diagrams which refuses to open.

This has been confirmed problematic on multiple Linux-systems: --> ArchLinux, XFCE/GNOME2-based (Up to date as of 2017-12-28) --> ArchLinux, KDE/Plasma5-based (Up to date as of 2017-12-28) --> Kubuntu, KDE/Plasma5-based (16.04LTS up to date as of 2017-12-28)

Build was explicitly done: --> ...without any custom patches/resources, and --> ...performed on each system, no copying pre-built, and --> ...build was successfully completed with QtCreator for first trail, and --> ...build was successfully completed for second trail using: qmake "zkanji.pro" -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug && make

Test(s) performed with all settings at default without imported data, dictionaries aside.

Double-checked all dictionary files being in correct format as specified in "Setting up the data files"-section. Both "kanjidic" or "kanjid212" yield crash, assuming the former being the preferred though. Also made an attempt with the fused UTF-8 containing "kanjidic", "kanjid212" & "kanjid213" with same result - dispite proper conversion to EUC-JP.

Is this related to the actual code in "smartvector.h" line 440-443 (see coredump), or the build options?

Coredump info on last core after crash, all say the same:

# Current GIT cloned @ 2017-12-28
$ gdb zkanji
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000558553b86e05 in smartvector<KanjiElement, std::allocator<KanjiElement*> >::operator[] (this=0x5585550aff08, n=18446744073709551615)
    at smartvector.h:442
442         return const_cast<value_base_type*>(base::operator[](n));

# v0.0.3-alpha.tar.gz, submitted @ 2017-08-09
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005596df98fb89 in smartvector<KanjiElement, std::allocator<KanjiElement*> >::operator[] (this=0x5596e1e61b08, n=18446744073709551615)
    at smartvector.h:442
442         return base::operator[](n);

# v0.0.2-alpha.tar.gz, submitted @ 2017-07-30
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000562a9b3c811f in smartvector<KanjiElement, std::allocator<KanjiElement*> >::operator[] (this=0x562a9e289048, n=18446744073709551615)
    at smartvector.h:442
442         return base::operator[](n);

-- Issue/Bug #2 --

On Linux and plausibly other systems as well: --> When importing user data at initial run, if browsing then closing the browsing-window (or using cancel), zKanji will hang. No coredump produced. No error seen when running through terminal.

-- Issue/Bug #3 --

On Linux and plausibly other systems as well: --> When using the "Minimize to tray" option, no icon is drawn at tray and it's impossible to restore window from the no-icon slot which appeared upon minimizing zKanji. Closing/restarting zKanji requires the use of terminal or GUI process handling tool - sending 15 works fine so it doesn't freeze or anything like that.

[z1dev]

Thanks for reporting these bugs. Can you also tell me which Qt version you are using? I tried all issues but couldn't reproduce them yet.

For #1 if the tooltip works, the kanji data must have been imported correctly. The coredump for the smartvector line is not very helpful, since I'm just calling the std::vector functions which is part of standard C++. The errors most likely mean that the index for accessing vector elements is out of range, so where this function is called from is the culprit, not the smartvector itself.

I tried #2 as well, but choosing cancel or closing the browse window doesn't make zkanji hang for me. Could you try to debug this and tell me which line is where the program hangs? The browse dialog is in an infinite loop in case the user wants to retry, so something happens there. I'll check, but it's hard to fix something when it doesn't show itself broken.

As for #3, this is the only one I also know of. There is no icon for the program, since I haven't added one yet for Linux, but clicking on the empty space brings the program up again.

[am2del]

In case you're unaware, Arch is a minimalistic approach for those who want maximum adaptability from their system - as raw as it gets without making custom compile of every single thing oneself. Also, Arch is rolling-release style and no direct versions like other systems.

Versions on the ArchLinux/XFCE are: (GNU/GPL) --> QT5 5.10.0-1 --> QTCreator 4.5.0-1 --> QTCurve 1.9.1-2 (GIT 20170710) --> PyQT5 5.9.2-2 --> QMake 3.1 --> Make 4.2.1

The ArchLinux/Plasma should have the same versions, but possibly more QT-packages installed as XFCE is primary GNOME/GTK2+. The Kubuntu machine I can't say on top of me head either, as I got neither of these two machines at hand atm. I'll come back later when I've had opportunity to check. I'm just administrator of those for acquaintances - who are in fact studying Japanese atm, beginner level still. (I get a lot of questions, as they know I learned Japanese on-site the Japanese way - and not through glossary or JLPT-style.)

Some of the issues MAY be related to packages/versions. I wouldn't dare to say for sure yet. I got limited abilities to test as I don't have an old spare computer around... Virtual machines and live ISO, great - but the results can differ from true installed environments.

For #1, I believe so too looking at those lines - not much can go wrong there. As mentioned in another post, I'll look into the coredumpctl/gdb and see what I can do. If you wish I can extract a dump and attach... if size is not an issue (200~250MB). Or attach an archive with a build that has the issue. Will also look into what can I get from trace, came to think of that option after my original post.

For #2, as mentioned in another post - my experience is primary Python and CLI-oriented, but I'll give it a shot. Saw there's a debug mode in QTCreator, I'll see how that works and also looking into trace.

For #3, the funny thing with this bug is that clicking that EMPTY-space does nothing at all. I don't know what DE you experiment with, but I would strongly recommend when working with GUI and Linux to test things in all major DE - e.g. Gnome, Mate, Plasma/KDE, LXDE, XFCE and Cinnamon - as these are the ones 90% or more of your future Linux users will have. If possible also test out in Gnome & Plasma/KDE under Wayland and not just standard X11 as Wayland is (likely) the future. Ubuntu is officially making Wayland primary from April 2018 I heard... may be a bit early still, but that's what they said in a press release. The old code and inefficiency of X11 has been a hot topic for about 10 years now, yet it's still great. Also, if possible - an old laptop or something would make a better (more accurate) test platform than a virual machine.

[z1dev]

My mail is not able to accept larger attachments than a few megabytes, and I'm not sure the dump would be useful anyway. I'll look into this now just to see where it could go wrong in theory and get back to you, just like the other two points.

[z1dev]

1 After some testing I found that if the stroke order database (zkanji.zks) is missing from the data folder, the kanji information window crashes, complaining about invalid vector positions. I never intended zkanji to run without this file. It would be best to notify the user of missing files, but I was too lazy to implement it. (You should also include "similar.txt" from the old program.) I fixed it for now by disabling the stroke order diagram and related widgets on the information window, but if it's referred to elsewhere, the program will still crash. It's on git if you want to test.

This might not be what causes the crash for you, but I thought it's worth mentioning.

[z1dev]

I'm using KDE since that's the only one I'm familiar with. I started the testing period with zkanji months ago to allow people to check it on their systems and get back to me with their findings. I don't have illusions about how well the current version might work elsewhere, but I'm hoping people with programming experience will sooner or later notice it. I don't have the time to test everything unfortunately.

The other two bugs are a mystery to me right now. Qt is supposed to take away the burden of developing to different systems, but it doesn't do a very good job at it.

[am2del]

For #1, I can confirm this is the issue. As the instructions didn't mention these, the current script doesn't copy dictionary-related files to the data folder as I expected the -ie flags to grab required files from the PATH specified. What about the "irregulars.txt" and "furigana.txt", are they needed for something too? Here's a screenshot of the Kanji dialog box with the Dark-Theme-Resources.zip applied: (slight interface scaling applied)

For #2 and #3, I'll look into those and come back. Just got limited time to spare the next few weeks so... don't expect results too soon.

Most DE's are Gnome (GTK-based), for a different perspective as developer you may want to try Gnome as well. Personally I favour Plasma/KDE (QT-based) since the introduction of GTK3, as GTK3 environment lacks several features I use a lot. Cinnamon (developed by/for Linux Mint) and Plasma/KDE are usually more confortable for those who got a Windows background. Aside from the GTK/QT-base difference, the DE's aren't really the issue when testing (won't say it still shouldn't be concidered tested though) - it's the distribution behind it. E.g. Debian/Ubuntu/Mint, Fedora, Suse, Arch/Manjaro etc. As they make different changes to the base Linux, you may get different results running Plasma/KDE on Ubuntu compared to running it on Fedora as the DE is a front-end while the differences lies behind it. Arch is likely the one with the least changes from the raw base as it targets users who know what they are doing - and users who want optimized system for their hardware & needs. When testing, which distribution do you use?

[am2del]

I want to say, the stroke numbering, stroke shadowing, stroke marking (red) and stroke playback stopped working after your last update to GIT.

-- Issue/Bug #4 --

-- MOVED HERE -- Gone ahead and done a bit of debugging... though still trying to figure out how to use the QTCreator debugger properly. The hang, now confirmed infinite loop, won't be reproduced from inside QTCreator... just when running it the normal way or under strace. Ran out of time for today, so posting the results so far.

All below is performed on raw GIT-source, and the files "zkanji.zks", "similar.txt", "irregulars.txt" & "furigana.txt" are present in the data folder.

In regards to the crash and hang, the reproduction procedure goes: -> Produce initial crash: --> Open zKanji --> Switch to "Japanese-to-English"-mode [F2] --> Click the "kanjipen.svg"-icon button --> Crash (See 1) -> After crash, zKanji won't start on first attempt: --> Start zKanji after crash (See 2) -> Start zKanji again: --> Now starting. --> Switch to "Kanji search"-mode [CTRL+4] --> In the "Radicals"-select box, choose "Select..." --> zKanji MAY hang (See 3)

It's more prone to occour when having both "Japanese-to-English" and "Kanji search" docked in same window. Preferably dock them, close and restart zKanji before trying to reproduce.

1) QTCreator debugger show:

QMainWindowLayout::cound: ?
The program has unexpectedly finished.
The process was ended forcefully.
.../build-zkanji-Desktop-Debug/zkanji crashed.

Debugger leads me to breakpoint 65533 in thread 1:

Lv1 QMessageLogger::warning(const char *,...) const
Lv2 ?? << Dissasembler(??) @ line 7:
0x7ffff6e01c9c                   48 8b 54 24 28              mov    0x28(%rsp),%rdx
Lv3 (anonymous namespace)::_scaleLayout in zui.cpp -> _scaleLayout(QLayout *): void @ line 533 (the for-loop)
Lv4 (anonymous namespace)::_scaleWidget in zui.cpp -> _scaleLayout(w->layout()) @ line 514
Lv5 (anonymous namespace)::_scaleWidget in zui.cpp -> _scaleWidget(w) @ line 568
Lv6 RecognizerForm::RecognizerForm in recognizerform.cpp @ line 481
Lv7 RecognizerObject::event in recognizerform.cpp @ line 831

Took a look at the code... but concluded I need more time to figure C++ out as I couldn't see nothing obvious.

2) QTCreator debugger show: .../build-zkanji-Desktop-Debug/zkanji exited with code 0 Code 0 should be after successful execution... which isn't the case as it doesn't properly start. Running: strace zkanji &> RefusingToStart.txt I'll attach the strace log from "After crash, zKanji won't start on first attempt:". RefusingToStart.txt

3) I managed to reproduce this issue at high frequency, but getting it for the first time seems fairly random when it occours. If it doesn't hang, start over from "Produce initial crash" and now and then it occours on any recent source (December -> New Years Eve). Once this issue has appeared the first time, it will enter the infinite loop EVERY TIME the radical search is opening. I've tried over and over in debug-mode to reproduce this but it simply doesn't happen. Running: strace zkanji &> OpeningRadicalSearch_EnterInfiniteLoop.txt It's stuck in a loop which sais: write(2, "QFont::setPointSize: Point size "..., 72QFont::setPointSize: Point size <= 0 (-n), must be greater than 0 ...where n is an integer constantly decreased by 1. I'll attach a strace log from "Start zKanji again:", and it enters the infinite loop (hangs) @ line 23795. I'll cut out some n=-26 to n=-106712 to reduce file size from 16MB to 2MB. Backtracing from there is probably easiest way. Unfortunately all mouse-movement is getting traced as well. OpeningRadicalSearch_EnterInfiniteLoop.txt

EDIT@3: Making the bug appear in a regular build outside of QTCreator, then replacing the files in Debug-folder with the ones from the build with bug managed to make the bug appear inside QTCreator as well... however not getting any traceback info at all. Just: QFont::setPointSize: Point size <= 0 (-n), must be greater than 0 ...where n is an integer and constantly decreasing by 1. Closing the zKanji (which is ran from QTCreator) doesn't make it stop, must force stop with kill-9.

[z1dev]

The other txt files are not needed for this version.

Does #4 appear in QtCreator only if you use files when running in regular builds? I'm not sure what could be different, but my guess is the settings files. If the issue shows itself with fonts, there might be different font settings in the two versions.

I think I know where the problem occurs. I had a very similar bug in the past with badly selected fonts, which is of course a problem in zkanji itself. Since the point size or pixel size for fonts don't necessarily result in text with the given size on screen, I try to find the best size by measuring a text bounding rectangle and changing the font's size in a loop. I'll need to fix the algorithm that does this, and stop the loop if the font can't be resized.

I don't know how to fix this yet, but with different font selection, this bug might not appear for you.

[z1dev]

I fixed the bug which made the handwriting tool crash right away. This bug also affected the kanji information window, which might have caused the shadow and other options to stop working. The bug with the fonts can still be around though.

[am2del]

Build-stamp (UTC): 2018-01-02 @ 13:31 (I'll attach build-stamps just to ease up potential trouble-shooting and relevance in case commitments been done after the build.)

I can confirm there's no longer any crash for the handwriting. I've also been unable to trigger the infinite loop issue/bug #4. I think it can crossed off the list.

I can also confirm the stroke numbering, stroke marking (red) and stroke shadowing is working again.

Regarding the "font size", as fonts cannot have negative size - could you add a breaker for the loop, e.g. if n<0 return FallbackSize? When I code things in Python, I usually build in some debugging aid things (especially alpha/beta components/stages) - an example for a case like this would be passing to a log "Warning: function X scaling negative size, returning fallback size.", possibly also the call source (if possible). A whole lot of these error-handlers could possibly affect performance slightly, but at the same time ease up - and speed up - troubleshooting... so it's a give and take when/where/if to use in my oppinion.

[am2del]

-- Issue/Bug #5 --

Easy fix, I think: Among filters in the "Kanji Search"-mode, filter no.7 and no.8 are cross-linked. So, when using the menu-click selecting "SKIP"-filter the "Index"-filter is shown (and marked) instead and when clicking the "Index"-filter the "SKIP"-filter is shown (and marked) instead.

[z1dev]

5 should be fixed in the GIT now.

There's no need to make a log for the font size issue because I know the possible causes, but I should make sure it doesn't go negative nor end up in an infinite loop. All the problems you saw before the crash was resolved were the result of invalid memory access, in which case completely unrelated things can appear buggy.

[am2del]

Build (UTC): 2018-01-04 @ 15:47

I can confirm #5 is fixed, the filters "SKIP" and "Index" are no longer cross-linked.

I'm sorry to inform the "infinite loop" issue/bug #4 has re-appeared in this build and it's EVERY time since first run after clean build (re-building and trying it still enters the loop). This time it's triggered directly by trying to open the Select Radical-filter. Changing fonts doesn't help at all, I tried out 20+ fonts where several are dedicated for Japanese/Chinese writing. Could this bug be fixed by using images as mentioned earlier? Btw, would it be a big deal if they're PNG and not SVG? (Probably got time for the radical digitalization during upcomming weekend.)

[z1dev]

I didn't have time to fix #4 yet, I'll take a look at it soon, but because the bug doesn't appear to me it might be difficult to find a fix.

I need SVG for the radicals to keep them scalable with the interface, besides clean vector graphics look more professional than scanned images which need extra work for a similar result. Instead of digitizing the radicals, using a free font to convert characters to SVG might work better. EDIT: Another reason against PNG is that it won't follow the system theme, unless you make it monochrome and change colors programmatically which is extra coding that could be avoided. But then anti-aliasing won't work, so I don't like this idea.

[z1dev]

Please check if #4 still happens. If it crashes for the same reason there is some strange issue going on, since I added checks against negative font sizes. It might crash elsewhere, but then the bug will be even harder to track.

[am2del]

Sorry, I've been busy with digitalizing the radical info. Moved all about SVG's and the file to the "Future feature request"-thread.

-- Update on #4 --

Build (UTC): 2018-01-05 @ 23:48 The bug remains.

Build (UTC): 2018-01-07 @ 15:43 As far as I can see, it's working now. Disclaimer: I haven't had much time to actually test yet (just a few times). Asked people to activate their update scripts and test it out 50+ times (with several fonts) and see if they can trigger it or not. I will get back to you as soon as I get their results, different systems/setups can yield different results afterall.

[am2del]

-- Update on #4 --

Build (UTC): 2018-01-07 @ 15:43 Radicals filter seems to be working fine, regardless of distribution and font settings.

[z1dev]

I'll close this issue to clean up the issues list, although I'm sure there are still things in here that were not solved. Please open an issue for specific problems if something remains.