dotnet35sp1 application crashes - Winlink (RMS Express, versions <1.5.41.0) #217
Comments
|
Found a bug in RMS Express after commit 549ff98 (that was done to help get VARA running). I just wanted to report it here to help debug. I don't think this was here before: The "HF Channel Selector" in RMS Express crashes and doesn't leave a wine debugger log:Running w/ box86 549ff98 using Note: wine-devel=5.18 opens RMS Express with just mono on x86 Linux The HF Channel Selector has to run before RMS Express will allow a user to select a channel and send a radio signal. |
|
New opcode request for VARA after compiling Box86 2375d70 |
|
Not sure when this cropped up because I haven’t tried to run the Winlink installer in a while, but I just tried to run Winlink installer with Box86 eaf7d0a (box86 version w signal handling for dotnet30) and got these new errors: errors:Updating to Box86 e449a4e I getThis all be a bit moot anyway though until signal handling works for dotnet35sp1 since dotnet35sp1 is a pre-requisite for Winlink, but just wanted to post this error here for future debugging |
|
Nice :) with 269bc9e (I believe), the Winlink installer runs again. |
|
With dotnet35sp1 now installing in box86 (#227), I'm looking at Winlink again. I'm getting some sigsegv's when trying to run it with just dotnet35sp1 installed. I've logged them with log1 here: log1.log I also tried updating box86 with today's commits, then installing some of the other components that VARA needs ( Log2 looks like this: morecomponents_log2.log.zip |
|
Thanks for the updated signal handling for dotnet! I’m getting these errors now when running RMS Express (dotnet35sp1) and WinRPR (dotnet40): |
|
Getting even farther with eca39e6 ! |
|
Log2 here: log2file (copy 1).log.zip :) |
|
We're getting so close now that .net is functioning. Winlink appears to error every OTHER time it opens (how odd), but not every time it opens. I'm still suspicious of ngen. A winlink error dialog box pops up whenever ngen appears in the terminal (".NET Runtime version 2.0.50727.3053"). Screenshot:
With log1 I get:Trying to install (and override in winecfg) any version of a native iphlpapi.dll from online that I can find gives me a bunch of new errors. I know ngen tries to do some kind of compiling thing on files so that they run faster the next time they're loaded. Maybe it's caching things (that are broken), crashing when it tries to load its cached files, then just rebuilding from scratch on the next run of the program. I'm still working on figuring out the best installation conditions, but so far I have: I'm also currently experimenting with other winetricks packages (any related to dll warnings I've seen in the log1 output) to see if any help. So far, I'm trying |
|
wtf. It appears to not be erroring anymore. Sorry, this whole process is confusing. Screenshot:
With this combo of overrides (ie with this combo of winetricks package installs) I'm not getting that crash anymore (and ngen isn't complaining).So I guess just install whichever packages include the following dll files that I didn't comment out here with I'll try to figure out which packages those are exactly |
|
(Sorry to spam - just kinda excited) I think I narrowed this ngen crash down to wine just missing EDIT: I found out that if I decide to install vb6run (so that winlink's internet works), then I needed to install these two things too I do still have all the other dll files in place in my wine system32 folder, so I'll try to see if it's truly just this dll or if Winlink/ngen need others too, but this is pretty exciting to think that ngen woes might just be from missing this crypt32.dll (ps I'm running Box86 dd733c4, wine_5.21-devel, TwisterOS) Another edit: I just tried some other combinations of things and wanted to post them here too. Packages recommended by K6ETA:
Tried:(sideloaded prefix means a wineprefix where dotnet35sp1 was installed using wine on x86 Linux and the wineprefix was transferred to the RPi4) Try next:dotnet35sp1 installer w/ crypt32 on older box86 builds which had crashes in the installer before |
|
With box86 9c5a9eb when I try to run RMS Express, the program seems to freeze now when trying to open. Log 1 shows this: I’ll try to bisect and find the commit. Maybe this is related to the new crashes in ngen/dotnet? |
|
That error appears to be a separate issue. I went back to the commit that has libcrypt wrapping and it appears that the wrapping isn’t playing nice with ngen. I’ll bisect that and log1 soon |
|
I’m having some trouble today pinning down which commit causes RMS Express to not open anymore. Part of my problem is that I broke test.sh somehow (I think by experimenting with RAM stuff). The other half of my problem is that RMS Express still has that initial crash that pops up and I’m having trouble sorting out maybe two different crashes. I’ll probably focus on dotnet35sp1 installer first and come back to this issue after that’s resolved |
|
Just wanted to say I’m excited to have put up a GitHub page to host an install script and hopefully make install easy for the hams I know: I’m so excited that VARA runs and am really looking forward to ironing out even more bugs and streamlining the dotnet install process. I’ve been trying to do this for two years and it wouldn’t have been possible to do it open-source without box86 and your help. Lots of work still to be done with Winlink on box86, but this is a pretty amazing proof of concept. I’ll keep looking for bugs 🙂 |
|
These crashes took a while to track down since they happen inconsistently (and I got kind of busy this month + side-tracked working on my Winelink script) RMS Express crashes happen whenever ngen crashes appear in the terminal (when running RMS Express): The .NET ngen.exe that RMS Express relies on is located here: After installing dotnet35sp1 (commit db5efa8 works to install dotnet35sp1), I believe we can test ngen alone by telling it to create a native image of any exe: ngen stores the native images that it creates in RMS Express testing notes (set up with my "Winelink" script, then removed native crypt32 from winecfg): |
|
Ok! So commit "d3d431d5" introduced some mutex mecanism, so I assume there is a deadlock happening here. If you can reproduce on your side (with latest box86 sources): once it's stuck, open another terminal, and with (in the mean time, I'll try to think of what could go wrong, but the backtrace would certainly help) |
|
Awesome, alright here's the backtrace of RMS Express with box86 be82ccb. ngen wasn't in the PID list. backtrace:The terminal running RMS Express (frozen) reads: |
|
Thanks for the update! I never thought to try this till now, but I turned off dynarec and that got past the freeze in the latest commit (c254dc3) and in the Feb 9 (a062a8e) commit (though in both cases after turning off Dynarec, after Winlink loads it then has internet errors and always crashes w ngen problems - though these are probably separate issues). |
|
Thank you again for your work on this error. The freeze is unfortunately still persisting. Freeze happens here in the terminalLog1Backtrace:With dynarec off the program opens: |
|
well, it seem the deadlock doesn't happens on main "RMS Express.exe" program, as it is waiting for an answer from another program. Maybe wineserver, maybe another, I cann't tell, be if it was a deadlock, you would see some thread of the backtrace waiting on nanosleep or pthread_mutex_lock. |
|
I will say, with dynarec off and with these patches, the other RMS Express crashes seem to be gone now and the internet works again |
|
At least something progress in the right direction! :) |
|
I thought maybe I should post a log1 and backtrace of ngen too since .NET's ngen freezes in the same spot as RMS Express in the terminal (I believe RMS Express invokes ngen while opening). Not sure if any of this helps, but here's Log1:And backtrace:ngen doesn’t freeze with dynarec off: |
|
I gave gdb another shot today with the C freeze with box86 74d3bb7 and found a reference to "nanosleep" in winedevice.exe I ran ngen again until freeze and then attached gdb to various processes and searched Here's the backtrace of winedevice.exe (process 10979 in my instance):I also searched these other processes but didn't find references to "nanosleep", "pthread_mutex_lock", or "mutex".These were the other processes in my instance (I thought these might not have as much of a chance to find anything interesting): |
|
With 00ac8ec , the freeze persists but nanosleep is gone from the backtrace of winedevice.exe. Nice work! |
|
Are you sure you will not miss some of the needed define, like "ARM" or "DYNAREC_ARM" building that way? |
|
Hm, cmake seems to ignore those defines. I still don't understand why. |
@bbbruni: It's all good! I welcome all your ideas and appreciate you trying. It was a good thought. Here's the SIGBUS loop: |
|
Ok, so SIGBUS means "unaligned access" (roughly). What I see is the x64opcodes are 55 57 56 53, so basicaly some "PUSH" opcode. The error is on accessing 0x62cdd91d wich is not a multiple of 4 address (but a multiple of 2). |
|
Thanks for the feedback on this. Don’t worry though, this is an old box86
commit from Feb 22. Bbbruni and I were trying to learn more about a .net
freeze in box64 by going back to this older problem in box86 and testing
things there. You were right to be surprised since this is an older commit.
The latest box86 (built today) does still crash when running .net apps (RMS
Express) though with dotnet35sp1 installed (installed with an older box86)
with this error:
```
0024:fixme:ntdll:EtwRegisterTraceGuidsW register trace class
{861f5339-19d6-4873-b350-7b03228bda7c}
0024:fixme:ntdll:EtwRegisterTraceGuidsW (7A030638, 00145008,
{cc2bcbba-16b6-4cf3-8990-d74c2e8af500}, 1, 7A3BEE38, (null), (null),
7A3BDC78): stub
0024:fixme:ntdll:EtwRegisterTraceGuidsW register trace class
{ea40c74d-4f65-4561-bb26-656231c8967f}
```
…On Fri, Oct 22, 2021 at 8:50 AM ptitSeb ***@***.***> wrote:
Ok, so SIGBUS means "unaligned access" (roughly).
What I see is the x64opcodes are 55 57 56 53, so basicaly some "PUSH"
opcode. The error is on accessing 0x62cdd91d wich is not a multiple of 4
address (but a multiple of 2).
I remember that PUSH/POP opcodes in the dynarec was having an issue on
unaligned stack pointer in the past, but I fixed that (by changing the
emited ARM codes).
I'm surprised to see this kind of error again.
Is the loop the same with current box86 code?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#217 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHCGVPSN42KXT5VDHADJWQDUIF24ZANCNFSM4SECK3RQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
I think I’m going to close this issue since it’s really a dotnet35sp1 and dotnet <4.8 issue. RMS Express and it’s modems seems to work ok in Box86 with wine-mono. There are some wine-mono bugs, but madewokherd and I are slowly working through those. RMS Express was also updated recently to require dotnet46 now instead of dotnet35sp1. So the premise of the issue has changed slightly as well (though dotnet46 is still reliant on older dotnets like 35 I think). I may open a generic =<dotnet46 thread with more updated info later |
|
Thank you again for all your hard work on this! I really sincerely appreciate all the time you’ve spent on this. I haven’t given up on it either, just migrating to a newer and more specific thread |
Sebastien seems to have fixed the analogous issue with RimWorld: ptitSeb/box64#110 (comment) Could you re-test RMS express with native .NET (not mono) with new two key switches with the latest box86? |
|
Just to note: |
|
😲 It works!!!!! Amazing job guys!! .NET 4.0, 4.5, & 4.6 (pre-req for the newest version of RMS Express) successfully install with RMS Express & VARA run with ARDOP seems to not want to run for some reason, but that's a lesser issue. I'll see if installing .NET 3.5 sp1 might fix that. |
|
.NET 3.5sp1 installs too. ARDOP weirdly doesn't want to run though - I've attached a log2. EDIT: Here's a log1 too ardop_box86log1.log ARDOP is a small program that's packaged in with RMS Express (Winlink Express). You can get it by installing Winlink Express, or download it standalone if you join the ARDOP developers google group: https://ardop.groups.io/g/developers/files/ARDOP_Win.exe |
|
I'll check ARDOP later. Is StrongMem "2" mode mendatory, or does it work with "1"? You should note that the performance penalty for StrongMem 2 is significant, so it should be used only when necessary (like CPU emulation can be 50% slower, that's what I measured on 7z benchmark on 64bits, need to try on 32bits) |
|
Just some preliminary testing: RMS Express seems to run ok with StrongMem off (and strongmem 1 or 2). Turning bigblock on seems to cause a crash every other time i load/run the RMS Express.exe though |
So it looks like RMS Express was fixed either by bff458d or by d116855. d116855 was merged earlier. Could you please help with finding out what commit gave the fix? checkout to d116855 and run If it still crashes, checkout to bff458d and run the same command |
|
I tested each of these commits by loading RMS Express four times and found these significant commits (bolded): System specs: RPi4 2GB, Twister OS buster, wine-devel 6.19, fresh wineprefix w/ dotnet46 & dotnet35sp1 (installed using box86 5368285). pale's test.sh helped a lot to bisect commits. I made this build_from_commit.sh script too#!/bin/bash
sudo apt-get install cmake -y
cd ~/box86
rm -rf box86
git clone https://github.com/ptitSeb/box86
cd box86/
git checkout 8373bee595c94e339bf6ed81748cd6ead9e88496
mkdir build; cd build; cmake .. -DRPI4=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo
make -j3
sudo make install # copies box86 files to /usr/local/bin/box86
sudo systemctl restart systemd-binfmt # essentially initializes box86
git checkout master |
|
Just did a little more testing and found more interesting info: dotnet35sp1 still appears broken in the latest box86 even though dotnet46 works great. Since all versions of RMS Express after/including v1.5.41.0 now use dotnet46 (versions before that used dotnet35sp1), this doesn't affect me. But I wanted to report in on it for bughunting. Old RMS Express, new box86: I'm attaching the old version of RMS Express v1.5.39.0 that uses dotnet35sp1, since I don't think you can find it on the internet. I'm also attaching some logs of the dotnet35sp1 crash (loading the old RMS Express) with newer box86 e255bc0 ( |
|
Thank you for your tests!
You were using box86 with dynarec on, right? I wrote the following text out of supposition you had launched RMS Express on [807519e] with dynarec on. Looking through box86 changes made by d3d431d, I've found something This commit removed a significant part of Could you check out to box86 built Jan 30, 2021 (807519e) and comment out lines 570-577 (including the latter) and line 582 in custommem.c? If RMSexpress freezes after that on 807519e, this is a very good sign. |
|
Thank you for continuing to look into the dotnet35sp1 errors and for trouble-shooting.
Yes, that was with Dynarec on.
I just checked-out box86 807519e, commented out those lines in It was a good thought! And I really appreciate your ideas. Let me know if I can test out other builds. |
|
We might check more new code fragments form d3d431d, which remain unreverted in main branch ;) delete lines 326, 327 and insert the following: |
|
Sorry for the delay! I got busy with Thanksgiving / Native American Heritage Day preparations and holiday stuff and then for some reason, I couldn't get RMS Express to run again with my old conditions - got that figured out again though today to do more testing. Ok, I made a fresh wineprefix with dotnet35sp1 and old RMS Express (the one that runs dotnet35sp1). I ran it successfully with old box86 again to make sure it was working. Then I checked-out box86 807519e again, commented out those lines again in (Side-note: I also checked-out box86 d3d431d too just to make sure I was understanding correctly - the file |
WheezyE
changed the title
|
Below is a guide on how I formed my equivalent patches. Imagine a beginner C programmer John Doe. This was the whole program. Then some third developer (Jim Smith) sends a buggy 'B1' commit causing data loss but John Doe doesn't know that it's buggy. Jim Smith does this by replacing Now John Doe decides to convert our program from multiplying the input value by 2 to multiplying that by 4. He does this by replacing Then John Doe forms a new 'C9' commit on top of that buggy commit, sends it and sees wrong results of the program (the regression observed was introduced by previous commit, but it's unclear for him as a beginner so far, maybe it was provoked by 'C9', maybe by 'B1') He conludes that for some cause bisecting is unavailable (unfeasible). However, he wants to know what would happen if there were no 'B1' in the repository at all. So, John Doe has a task to seamlessly remove an intermediate commit between two others. Let's have a close look at 'B1' commit to find out what prevents John Doe from removing it from his repo. There are multiple rules to be obeyed so that it would be possible to apply some patch on top of another patch. (I don't pretend to be an expert on the subject, though) Both a patch created with The difference is that the former has some meta-information about the commit at the beginning of its text: SHA1 for the commit, time of committing, the name of the committer and his contact data, the subject of the commit (its name), the general number of files to be modified by the commit. A normal way to apply the former is Mistakes in the next area of a diff (or a git patch) are unallowable. git-compatible diff file starts with Immediately after this info, one or more change hunks are placed. A change hunk is comprised of range information [1] Range information consists of one line as follows: original file; additions and deletions have been made by previous hunks (if the current hunk is 2nd or consequent); The rules to be obeyed by each hunk: To give an example, let's imagine a text file containing just an ordinal at every new line: A whole .patch file (plain .patch file, not a git-compliant one) replacing 1,2 and 10 respectively with "newline" and "yet another new line" would look as follows (two-hunk version): A one-hunk version of that patch doing absolutely the same: Now let's look into how both two-hunk and one-hunk patches work. Firstly, it searches for /src directory alongside the patch itself and then for textfile.txt Then it analyzes the values of Then it analyzes the values of Then it compares the set of contextual lines of the hunk with that of actual contextual lines. After that, it compares the order of contextual lines in the hunk with that of contextual lines in the original file. Example of how two-hunk version of the file Firstly, the parser opens file *** Note that original file has lines containing In the next hunk, the parser analyzes So, after applying the previous hunk, the original starting line number of the current hunk in Example of how one-hunk version of the file Firstly, the parser opens file Resulted file looks as follows Now, let's get back to John Doe's problem. How can we determine which commit - B1 or C9 - has caused the problem? We may try to look what could happen if B1 were seamlessly removed (as if B1 never existed at all and the original file were patched directly by C9). How to see desired results of supposed removal? At the beginning, we must find out if we can apply C9 directly on top of the original file. If we can, it's better to do so. So, how can we see whether C9 can be applied directly without broken hunks? There is a rule of thumb: if properly ordered contextual and deletion lines from all hunks of the patch are present in the original file to be patched (in the correct consequence!), the patch is correct and can be applied. If some deletion lines are present in hunks but miss in the original file, patch program may complain that the patch was applied before and generate a rejection. In regard to John Doe's situation, contextual lines which present in C9 lack in the original file: *** original file *** *** C9 commit *** Even though all deletion lines from C9 are present in the orginal file, we cannot apply C9 right on top of it: contextual How can we modify the patch to make it appliable? We must roll back all C9's changes made by B1 so that C9 can be applied on top of the original file in a seamless way. Firstly, we need to remove all the lines added by B1. In regard to John Doe's situation, we have to remove *** C9-equivalent *** As you can see, in essense, we combine the INVERSION of B1 and C9 into a sole patch - C9-equivalent. John Doe applies C9-equivalent.patch and sees that his program prints 800 (200 * 2 * 2 or bitwise left shift of 200 by two places) as expected. So his commit C9 is right, B1 is wrong. |
|
Does this ticket still need to be open? |
|
Thanks for checking in. I’ll testb there today and report back
…On Wed, May 11, 2022 at 2:02 PM bbbruni ***@***.***> wrote:
@WheezyE <https://github.com/WheezyE>
Below is a guide on how I formed my equivalent patches.
Imagine a beginner C programmer John Doe.
Say, John Doe has composed a C program calculating the doubled value of a
short number.
He used bitwise left shift operator to do this kind of calculation
(bitwise left shift of a number by one place means multiplication of that
by 2).
Say, he has a working initial file after an accomplished 'A1' commit as
follows
#include <stdio.h>
int main() {
short number;
number = 200;
number <<= 1; /*bitwise left shift of 200 by one place means multiplication of 200 by 2, resulting in 400*/
printf("value of number is %u", number);/*it prints the product of 200 and a power of 2 until someone breaks the program*/
return 0;
}
This was the whole program.
Then some third developer (Jim Smith) sends a buggy 'B1' commit causing
data loss but John Doe doesn't know that it's buggy. Jim Smith does this by
replacing short with char.
///downcasting
///
#include <stdio.h>
int main() {
char number;
number = 200;
number <<= 1; /*bitwise left shift of 200 by one place means multiplication of 200 by 2, resulting in 400*/
printf("value of number is %u", number);/*it prints the product of 200 and a power of 2 until someone breaks the program*/
return 0;
}
Now John Doe decides to convert our program from multiplying the input
value by 2 to multiplying that by 4. He does this by replacing <<= 1 with <<=
2
#include <stdio.h>
int main() {
char number;
number = 200;
number <<= 2; /*bitwise left shift of 200 by one place means multiplication of 200 by 2, resulting in 400*/
printf("value of number is %u", number);/*it prints the product of 200 and a power of 2 until someone breaks the program*/
return 0;
}
Then John Doe forms a new 'C9' commit on top of that buggy commit, sends
it and sees wrong results of the program (the regression observed was
introduced by previous commit, but it's unclear for him as a beginner so
far, maybe it was provoked by 'C9', maybe by 'B1')
John Doe is a C beginner and ignorant of possible data loss during bitwise
operations.
He is ignorant that char type has range of valid values only from -128 to
+127 (which is true in real life).
He is thus ignorant that number <<= 2; line has overfilled valid range
for char type.
He conludes that for some cause bisecting is unavailable (unfeasible).
However, he wants to know what would happen if there were no 'B1' in the
repository at all.
At that point of time, he doesn't know whether 'B1' or 'C9' introduced the
regression.
Now he plans to seamlessly remove 'B1' from the repo to determine if 'C9'
works as it should after that it has been applied directly on top of 'A1'.
So, John Doe has a task to seamlessly remove an intermediate commit
between two others.
Let's have a close look at 'B1' commit to find out what prevents John Doe
from removing it from his repo.
There are multiple rules to be obeyed so that it would be possible to
apply some patch on top of another patch.
Firstly, let's observe some notions from the field of commits and patches.
------------------------------
(I don't pretend to be an expert on the subject, though)
Both a patch created with git format-patch and one created with git diff
(or diff --git) effectively does the same.
The difference is that the former has some meta-information about the
commit at the beginning of its text: SHA1 for the commit, time of
committing, the name of the committer and his contact data, the subject of
the commit (its name), the general number of files to be modified by the
commit.
Some mistakes in this meta-data area (the area is absent in diff files)
are usually not critical.
To give an example, one may specify wrong git-hashes and this won't hinder
patches (in case the rest of the patch is correct) from being applied.
A normal way to apply the former is git-am whereas patches created with git
diff or diff -u are usually applied by means of git apply.
Mistakes in the next area of a diff (or a git patch) are unallowable.
git-compatible diff file starts with diff --git a/original_file.c
b/modified_file.c
the next line is index old_git_hash..new_git_hash access_mode (however,
if there are mistakes in git-hashes, it won't stop the patch from being
applied)
There is file information at the beginning of the area, including the full
or relative path and an optional time stamp delimited by a tab character in
case timestamp was specified.
The format looks as follows:
--- /src/custommem.c 1999-12-31 23:59:59.999999900 +0100
+++ /src/custommem.c 1999-12-31 23:59:59.999999900 +0100
Immediately after this info, one or more change hunks are placed.
A change hunk is comprised of range information [1]
and line modification data which are usually composed of line additions
[2],
line deletions[3], and some number of the contextual lines[4].
Range information consists of one line as follows:
@@ -u,v +x,y @@ optional section heading
where
'u' stands for the ordinal number (for the file being modified) of the
first (usually contextual) line in this change hunk in the
original file;
'v' stands for the sum of contextual lines and the number of line
deletions in current hunk;
'x' stands for the ordinal number (for the file being modified) of the
first (usually contextual) line in this change hunk after
additions and deletions have been made by previous hunks (if the current
hunk is 2nd or consequent);
'y' stands for the sum of contextual lines and the number of line
additions in current hunk.
The rules to be obeyed by each hunk:
Line additions are prepended with "+" (and usually highlighted in green in
automatic way in specialized text editors).
Line deletions are prepended with "-" (and usually highlighted in red in
automatic way in specialized text editors).
Contextual lines look like normal text lines but must be prepended by an
extra space symbol.
"-0,0" in range information usually means that the original file was
absolutely empty before patching.
In the first hunk, 'x' matches 'u' if it's the first hunk and file was not
empty.
Default number of contextual lines is 3.
Each hunk has 3 contextual lines before any additions/deletions and 3
contextual lines after any additions/deletions.
If there was too few text lines in the original file, contextual lines of
a hunk may be less than 3 or lacking.
If there's no empty new line at the very end file, i.e. the very last line
in the file contains a contextual/additional/deletion line, then a new line
"\ No newline at end of file" must be insterted after it. After "\ No
newline at end of file" must be inserted an empty new line.
To give an example, let's imagine a text file containing just an ordinal
at every new line:
1
2
3
4
5
6
7
8
9
10
11
A whole .patch file (plain .patch file, not a git-compliant one) replacing
1,2 and 10 respectively with "newline" and "yet another new line" would
look as follows (two-hunk version):
--- a/src/textfile.txt
+++ b/src/textfile.txt
@@ -1,5 +1,4 @@
-1
-2
+newline
3
4
5
@@ -7,5 +6,5 @@
7
8
9
-10
+yet another new line
11
A one-hunk version of that patch doing absolutely the same:
--- a/src/textfile.txt
+++ b/src/textfile.txt
@@ -1,11 +1,10 @@
-1
-2
+newline
3
4
5
6
7
8
9
-10
+yet another new line
11
Now let's look into how both two-hunk and one-hunk patches work.
Firstly, it searches for /src directory alongside the patch itself and
then for textfile.txt
It reports an error in case src directory of textfile.txt is missing.
Then it parses @@ -u,v +x,y @@ line.
Note that if one composed a partly working patch, they may run into a
situation where some of all of hunks are applied and others aren't.
<<<<<< or >>>>>> literals in the file to be modified are a sign of such a
situation.
A usual solution is to abort the last operation.
Then it analyzes the values of -u,v.
u is the number of start line where the processing framework begins to
search contextual lines or (if the ones are missing) addition or deletion
ones of the hunk in the original file.
Then it compares the value of v with the actual sum of the count of
contextual lines and the count of deletion lines in the hunk.
If they do not match, this part of the patch may fail. One can see <<<<<<
or >>>>>> literals in the file later.
Then it analyzes the values of +x,y.
x is the number of start line where the processing framework begins to
search contextual lines or (if the ones are missing) addition or deletion
ones of the hunk in the file after previous hunks were applied.
Then it compares the value of y with the actual sum of the count of
contextual lines and the count of addition lines in the hunk.
If they do not match, this part of the patch may fail. One can see <<<<<<
or >>>>>> literals in the file later.
Then it compares the set of contextual lines of the hunk with that of
actual contextual lines. After that, it compares the order of contextual
lines in the hunk with that of contextual lines in the original file.
If they do not match, this part of the patch may fail.
Example of how two-hunk version of the file src/textfile.txt works:
Firstly, the parser opens file src/textfile.txt and analyzes lines
starting with 1-st line of file, including the 1-st line (since the first
hunk has @@ -1,). Then it checks the number of contextual and deletion
lines between @@ and the end of the hunk, ignoring addition lines. -1
(deletion) is the 1st line, -2 (deletion) is the 2nd, 3 (contextual) is
the 3rd, 4 (contextual) is the 4th, 5 (contextual) is the 5th. 5 lines in
total, which matches ...,5 +..., which is ok. Next, the parser checks the
number of contextual and addition lines between @@ and the end of the
hunk, ignoring deletion lines. +newline (addition) is the 1st line, 3
(contextual) is the 2nd line, 4 (contextual) is the 3rd line, 5
(contextual) is the 4th line. 4 lines in total, which matches ...,4 @@,
which is ok. Note that both -1 and +1 has number one, this is because no
hunks was analyzed before and lines were not shifted by previous hunks.
*** Note that original file has lines containing 1, 2, 3, 4, 5, so this
hunk can execute -1 and -2, deleting them. If the original file contained
2, 1, 3, 4, 7, this hunk would fail since it had no right lines in place
(2,1,7 are mismatching lines). So this hunk succeeds and the parser goes to
the next hunk. ***
In the next hunk, the parser analyzes @@ -7,5 +6,5 @@. So it sees that
the lines to be modified by this hunk must start from line 7 of the
original file, the parser ignores changes made by previous hunks when
determining the number of line 7 for this purpose.
Then it checks the number of contextual and deletion lines between @@ and
the end of the hunk, ignoring addition lines. 7 (contextual) is the 1st
line in the hunk, 8 (contextual) is the 2nd, 9 (contextual) is 3rd, -10
(deletion) is 4th, 11 (contextual) is 5th. 5 lines in total, which
matches @@ -7,5 ..., which is ok. Next, the parser checks the number of
start line, taking into account line shift made by previous hunks. In the
previous successful hunk, we had two deletion and one addition line.
So, after applying the previous hunk, the original starting line number of
the current hunk in +x,y section becomes one line less. 7-1 is 6. Next,
the parser checks the number of contextual and addition lines between @@
and the end of the hunk, ignoring deletion lines. 7 (contextual) is the
1st line, 8 (contextual) is the 2nd line, 9 (contextual) is the 3rd line, +yet
another new line (addition) is the 4th, 11 is 5th. 5 lines in total,
which matches @@... +6,5, which is ok.
Example of how one-hunk version of the file src/textfile.txt works:
Firstly, the parser opens file src/textfile.txt and analyzes lines
starting with 1-st line of file, including the 1-st line (since the first
hunk has @@ -1,). Then it checks the number of contextual and deletion
lines between @@ and the end of the hunk, ignoring addition lines. -1
(deletion) is the 1st line, -2 (deletion) is the 2nd, 3 (contextual) is
the 3rd, 4 (contextual) is the 4th, 5 (contextual) is the 5th, 6
(contextual) is the 6th, 7 (contextual) is the 7th, 8 (contextual) is the
8th, 9 (contextual) is the 9th, -10 (deletion) is the 10st line, 11
(contextual) is the 11th. 11 lines in total, which matches ...,11 +...,
which is ok. Next, the parser checks the number of contextual and addition
lines between @@ and the end of the hunk, ignoring deletion lines.
+newline (addition) is the 1st line, 3 (contextual) is the 2th, 4
(contextual) is the 3rd, 5 (contextual) is the 4th, 6 (contextual) is the
5th, 7 (contextual) is the 6th, 8 (contextual) is the 7th, 9 (contextual)
is the 8th, +yet another new line (addition) is the 9th, 11 (contextual)
is the 10th. 10 lines in total, which matches ...,10 @@, which is ok.
Resulted file looks as follows
newline
3
4
5
6
7
8
9
yet another new line
11
Now, let's get back to John Doe's problem.
How can we determine which commit - B1 or C9 - has caused the problem?
We may try to look what could happen if B1 were seamlessly removed (as if
B1 never existed at all and the original file were patched directly by C9).
How to see desired results of supposed removal?
At the beginning, we must find out if we can apply C9 directly on top of
the original file. If we can, it's better to do so.
So, how can we see whether C9 can be applied directly without broken hunks?
There is a rule of thumb: if properly ordered contextual and deletion
lines from all hunks of the patch are present in the original file to be
patched (in the correct consequence!), the patch is correct and can be
applied. If some deletion lines are present in hunks but miss in the
original file, patch program may complain that the patch was applied before
and generate a rejection.
In regard to John Doe's situation, contextual lines which present in C9
lack in the original file:
*** original file ***
#include <stdio.h>
int main() {
short number;
number = 200;
number <<= 1; /*bitwise left shift of 200 by one place means multiplication of 200 by 2, resulting in 400*/
printf("value of number is %u", number);/*it prints the product of 200 and a power of 2 until someone breaks the program*/
return 0;
}
*** C9 commit ***
--- a/src/textfile.txt
+++ b/src/textfile.txt
@@ -1,9 +1,9 @@
#include <stdio.h>
int main() {
char number;
number = 200;
- number <<= 1; /*bitwise left shift of 200 by one place means multiplication of 200 by 2, resulting in 400*/
+ number <<= 2; /*bitwise left shift of 200 by one place means multiplication of 200 by 2, resulting in 400*/
printf("value of number is %u", number);/*it prints the product of 200 and a power of 2 until someone breaks the program*/
return 0;
}
Even though all deletion lines from C9 are present in the orginal file, we
cannot apply C9 right on top of it: contextual char number; line lacks in
the original file because it was brought in by B1 just before C9.
How can we modify the patch to make it appliable?
We must roll back all C9's changes made by B1 so that C9 can be applied on
top of the original file in a seamless way.
We will call the new patch C9-equivalent.patch
Firstly, we need to remove all the lines added by B1.
Secondly, we need to add all the lines removed by B1.
In regard to John Doe's situation, we have to remove char number; line
and insert short number; instead of it (and the rolling back is complete).
Then we have to re-calculate numbers in @@ -u,v +x,y @@ line.
*** C9-equivalent ***
--- a/src/textfile.txt
+++ b/src/textfile.txt
@@ -1,9 +1,9 @@
#include <stdio.h>
int main() {
- char number;
+ short number;
number = 200;
- number <<= 1; /*bitwise left shift of 200 by one place means multiplication of 200 by 2, resulting in 400*/
+ number <<= 2; /*bitwise left shift of 200 by one place means multiplication of 200 by 2, resulting in 400*/
printf("value of number is %u", number);/*it prints the product of 200 and a power of 2 until someone breaks the program*/
return 0;
}
As you can see, in essense, we combine the INVERSION of B1 and C9 into a
sole patch - C9-equivalent.
Re-calculating sums of context lines plus deletion lines and context lines
plus addition lines gives @@ -1,9 +1,9 @@
John Doe applies C9-equivalent.patch and sees that his program prints 800
(200 * 2 * 2 or bitwise left shift of 200 by two places) as expected. So
his commit C9 is right, B1 is wrong.
—
Reply to this email directly, view it on GitHub
<#217 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHCGVPSXVARYEKYKVJKHD3TVJQG37ANCNFSM4SECK3RQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
.NET 3.5sp1 & .NET 4.6 seem to be working with wine-mono, but there might be some network issues (I'm going to check later if those are from box86 or from wine-mono). Installing dotnet35sp1 or dotnet48 still seems to have issues. Since RMS Express runs with wine-mono though. And since the issue kind of grew into other issues and isn't well-defined at this point, I think I'll close this and open a new issue with more specific goals. Here's some interesting info. RMS Express + VARA performance
Dotnet installation attempts
Installing .NET 4.6 with or without envvars crashes (BOX86_DYNAREC_BIGBLOCK=0 BOX86_DYNAREC_STRONGMEM=1 BOX86_NOBANNER=1 winetricks -q dotnet46) Box86 with Dynarec v0.2.7 9c30029 built on Aug 5 2022 21:41:51 |
Seb, thank you again for all your hard work with this finicky program. The commits from today (commits near c7a4dbe I think?) are getting RMS Express to open (and connect to Telnet!) with mono - which is farther than ExaGear got using mono.
I did some analysis today using mono vs using dotnet35sp1+vcrun2015 (from my pre-loaded dotnet35sp1+vcrun2015 wineprefix from my Debian 10 x86 VMWare virtual computer on my Windows laptop copied to my Pi --- vcrun2015 and dotnet35sp1 still crash when trying to install in box86 on the Pi).
Total packages needed for RMS Express and VARA to work (as learned from a functioning/clunky wine+ExaGear install) are:
winetricks -q corefonts dotnet35sp1 vb6run vcrun2015 sound=alsa win7 # VARA also needs an old WinNT4.0 pdh.dllEDIT 8/1/2021: More testing has revealed that these are the only packages needed for each program ...
BOX86_NOBANNER=1 winetricks -q dotnet35sp1 win7 sound=alsa# for RMS Express (corefonts & vcrun2015 appear to be optional)BOX86_NOBANNER=1 winetricks -q vb6run pdh_nt4 win7 sound=alsa# for VARAOverview
With mono (not dotnet35sp1) installed, RMS Express opens(!) and the ARDOP and WINMOR modems open. But ARDOP and WINMOR don't function correctly (I learned from ExaGear that they need dotnet35sp1 to function correctly, VARA needs vcrun2015). With dotnet35sp1 installed (instead of mono), I get SIGSEGV's running RMS Express, ARDOP, WINMOR, and VARA. VARA installs, but doesn't run with mono nor with dotnet35sp1.
RMS Express
RMS Express w/ mono: Runs!!! No problems! Telnet works! modems don't work though
RMS Express w/ dotnet35sp1:
RMS Express w/ dotnet35sp1+vcrun2015:
VARA
VARA install (still needs vcrun2015):
VARA (with and without Dynarec) w/ mono (no vcrun2015):
VARA (with and without dynarec) w/ dotnet35sp1 (no vcrun2015):
VARA (with and without dynarec) w/ dotnet35sp1+vcrun2015:
WINMOR (EDIT 8/1/2021: WINMOR has been discontinued)
WINMOR w/ mono: Runs! Doesn't function correctly:
wine WINMOR\ TNC.exe #w/ dotnet35sp1
WINMOR w/ dotnet35sp1+vcrun2015 (WINMOR doesn't need vcrun2015 to function though):
ARDOP
ARDOP w/ mono: Runs! Doesn't function correctly:
wine ARDOP_Win.exe #w/ dotnet35sp1
The text was updated successfully, but these errors were encountered: