Re: Re: quit files

"Joe Monk [email protected] [hercules-390]" <[email protected]>
Newsgroups gmane.comp.emulators.hercules390.general
Message-ID <CAPcd4G_JQOKo161pc1EErdNOJmx8BjVoTJdc=Yzs=K1Qf=ByRw@mail.gmail.com>
Juergen,

HHC01603I quit

HHC01420I Begin Hercules shutdown

HHC01423I Calling termination routines

HHC02272I Highest observed MIPS and IO/s rates

HHC02272I   from Sun Jun 23 00:00:00 2019

HHC02272I     to Sun Jun 23 06:06:28 2019

HHC02272I   MIPS: 23.761475  IO/s: 1652

HHC00101I Thread id 70000DEB3000, prio 16, name Socket device listener ended

HHC00101I Thread id 70000DDB0000, prio 16, name HTTP server ended

HHC00101I Thread id 70000DBAA000, prio 16, name Processor CP00 ended

HHC01465I 0:0002 device detached

HHC01465I 0:000E device detached

HHC01465I 0:000C device detached

HHC01465I 0:000D device detached

HHC01465I 0:0480 device detached

HHC01465I 0:010C device detached

HHC01465I 0:010D device detached

HHC01465I 0:000F device detached

HHC01465I 0:030E device detached

HHC01465I 0:001F device detached

HHC01465I 0:00C0 device detached

HHC01465I 0:00C1 device detached

HHC01465I 0:00C2 device detached

HHC01465I 0:00C3 device detached

HHC01465I 0:00C4 device detached

HHC01465I 0:00C5 device detached

HHC01465I 0:00C6 device detached

HHC01465I 0:00C7 device detached

HHC01465I 0:03C0 device detached

HHC01465I 0:03C1 device detached

HHC01465I 0:03C2 device detached

HHC01465I 0:03C3 device detached

HHC01465I 0:03C4 device detached

HHC01465I 0:03C5 device detached

HHC01465I 0:03C6 device detached

HHC00101I Thread id 70000DFB6000, prio 16, name Console connection ended

HHC01465I 0:03C7 device detached

HHC01465I 0:0610 device detached

HHC01465I 0:0611 device detached

HHC01465I 0:0660 device detached

HHC01465I 0:0661 device detached

HHC01465I 0:0662 device detached

HHC01465I 0:0663 device detached

HHC01465I 0:0664 device detached

HHC01465I 0:0665 device detached

HHC01465I 0:0666 device detached

HHC01465I 0:0667 device detached

HHC01465I 0:0668 device detached

HHC01465I 0:0669 device detached

HHC01465I 0:066A device detached

HHC01465I 0:066B device detached

HHC00101I Thread id 70000FB07000, prio 16, name 0:0670 communication thread
ended

HHC01465I 0:0670 device detached

HHC00101I Thread id 70000FC0A000, prio 16, name 0:0671 communication thread
ended

../start_herc: line 48: 34433 Segmentation fault: 11  $force_arch hercules
-f conf/tk4-.cnf > log/3033.log


The reason the log is not getting completed is because of a seg fault...



Joe

On Sun, Jun 23, 2019 at 4:52 AM [email protected] [hercules-390] <
[email protected]> wrote:

>
>
> Hi Paul
>
> I do acknowlege your error report. It is a known error, showing itself in
> a new light. To be exact, it is one of two major issues that prevented me
> since April from releasing the SDL Hyperion binaries to the TK4- community
> (you might have seen that the binaries you are using now are dated March
> 7th).
>
> Because I was never able to reproduce it under TK4- Hercules, I saw this
> error up to now in the light of something that was newly introduced with
> using SDL Hyperion. So your weird "pull the plug" usecase has at least one
> positive aspect: It proves that the error was already present in TK4-
> Hercules, but is simply occuring with such a low probability that under
> "normal" usage it never happens.
>
> So, what now:
>
> As we all know and have got demonstrated once again just now, race
> conditions depend on probabilities for the occurance of certain scenarios..
> Each of the scenarios is in itself deterministic, but there are side
> conditions that take influence on which scenario is occuring at a specific
> point in time. As long as those side conditions are not identified, the
> whole program seems to show arbitrary behavior.
>
> I was trying to shoot this bug down since April (with pauses due to sheer
> desperation). One of my major problems during analysis was, that
> reproducability was so weak, that, while having a relatively clear idea
> where it sits, I never managed to nail it down. Your weird usecase should
> change this, as it is now occuring relatively often, almost reliably ;-).
>
> Nonetheless, before opening the chase again, I must make sure being really
> chasing the _same_ bug (as opposed to a similar but distinct one hiding in
> the same area). In May, I made new binaries containing a kludge with which
> I was hoping to come closer to the bug. These binaries don't fix anything
> (because to fix something it needs to get nailed down first) but they
> change the probability of the occurance of the bug.
>
> So I'd appreciate if you could do the following test for me: Try to find
> out, with a minimal statistic signifance, how often the bug occurs under
>
> (a) The original TK4- Hercules
> (b) The SDL Hyperion binaries you are using now
> (c) The binaries with the kludge
>
> So, for example, fire up TK4-, then do your weird "quit", and repeat it
> until the problem has occured 10 times. Then report the number of runs you
> needed to reach this. Do this for all three versions. Repeat this cycle a
> few times to see if the ranking is stable. If it is not stable, nothing
> helps but acquiring more samples, i.e. do it until 20, 30, and so on. Not
> reaching a stable ranking can of course also be a result. I know that's
> tedious, sorry about that!
>
> I on purpose don't say what outcome I expect, to avoid biases.
>
> To install the "binaries with the kludge" for (c) download
> https://polybox.ethz.ch/index.php/s/OrtQJFQaScNJN2c/download and unzip it
> into the tk4- folder that has your current SDL Hyperion binaries activated.
>
> Thanks in advance for reporting back.
>
> Cheers
> Jürgen
>
> ---In [email protected], <kerravon86@...> wrote :
>
> ---In [email protected], <kerravon86@...> wrote :
>
> > 1. Unzip standard TK4-8
> > 2. Unzip below download
> > 3. Make this change:
>
> Sorry, there was also:
>
> 2.5 Run activate_SDL
>
> BFN. Paul.
>
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.