Nightly builds for Win32 and OS/2

[Andre Grueneberg]

* Original message posted in: BINKD.
* Crossposted in: RU.BINKD.
Hi All

I just wanted to announce that I've setup an automated build environment for
BinkD. This generates nightly builds (in case there are changes in CVS) of the
latest binkd source, both CVS HEAD and 1.0 stable branch.

Primary target is to verify that the source builds in several target compilers
and environments. I am considering to setup automated mails in case of build
failures at a later stage.

Currently the following targets are (cross-)compiled:
- Linux x64 using gcc (native)
- Linux x64 using clang (native)
- OS/2 using OpenWatcom 1.9
- Win32 using MinGW32/GCC

All targets are compiled with zlib, bzlib2, proxy, bandwidth limiting, FSP1035
(SRV lookup in binkp.net) and IPv6 (where available). Embedded Perl support is
currently not planned.

Upon completion the source as well as the binaries for OS/2 and Win32 are
published to http://binkd.grueneberg.de/.

Feel free to test those binaries, at your own risk, as usual. :)

I am open for improvement ideas.

CU Andre E-Mail: ***@grueneberg.de

[Tommi Koivula]

Tuesday July 03 2012 22:56, Andre Grueneberg wrote to All:

AG> Currently the following targets are (cross-)compiled:
AG> - OS/2 using OpenWatcom 1.9

It works!

'Tommi

[Tommi Koivula]

Wednesday July 04 2012 18:26, Tommi Koivula wrote to Andre Grueneberg:

AG>> - OS/2 using OpenWatcom 1.9
TK>
TK> It works!

Well, it does not. :(

19:41 [3] DosRequestMutexSem retcode 0x69
19:41 [3] Closing server socket # 32119
19:41 [1] downing servmgr...
19:41 [2] downing clientmgr...

'Tommi

[Andre Grueneberg]

Hi Tommi

Tommi Koivula schrieb:

AG>>> - OS/2 using OpenWatcom 1.9
TK>> It works!
TK> Well, it does not. :(
TK> 19:41 [3] DosRequestMutexSem retcode 0x69
TK> 19:41 [3] Closing server socket # 32119
TK> 19:41 [1] downing servmgr...
TK> 19:41 [2] downing clientmgr...

That's bad news. What happened before these messages? I.e. any clue how to
reproduce it? At least 0x69 means "Error, The semaphore owner has died without
releasing the semaphore".
So far this sounds like a generic issue in the multi-threaded version of binkd.

CU Andre E-Mail: ***@grueneberg.de

[Harald Kamm]

Ciao Andre,

Replying to a message of Andre Grueneberg to Tommi Koivula:

AG> That's bad news. What happened before these messages?

Here it works perfectly up to now.

Servus, Harald!

[Tommi Koivula]

Thursday July 05 2012 05:54, Harald Kamm wrote to Andre Grueneberg:

AG>> That's bad news. What happened before these messages?
HK>
HK> Here it works perfectly up to now.

Good for you! Maybe it is my weird system only -error. :)

My own kLIBC version works ok.

'Tommi

[Andre Grueneberg]

Hi Tommi

Tommi Koivula schrieb:

TK> Good for you! Maybe it is my weird system only -error. :)
TK> My own kLIBC version works ok.

Because it uses multiple processes instead of threads.

CU Andre E-Mail: ***@grueneberg.de

[Tommi Koivula]

04 Jul 12 23:12, you wrote to me:

AG>>>> - OS/2 using OpenWatcom 1.9
TK>>> It works!
TK>> Well, it does not. :(
TK>> 19:41 [3] DosRequestMutexSem retcode 0x69
TK>> 19:41 [3] Closing server socket # 32119
TK>> 19:41 [1] downing servmgr...
TK>> 19:41 [2] downing clientmgr...

AG> That's bad news. What happened before these messages? I.e. any clue
AG> how to reproduce it?

I ran it also with -cC so it is related to the client. It always happens after
running some time.

AG> At least 0x69 means "Error, The semaphore owner
AG> has died without releasing the semaphore". So far this sounds like a
AG> generic issue in the multi-threaded version of binkd.

Ok..

'Tommi

[Andre Grueneberg]

Hi Tommi

Tommi Koivula schrieb:

AG>> That's bad news. What happened before these messages? I.e. any clue
AG>> how to reproduce it?
TK> I ran it also with -cC so it is related to the client. It always
TK> happens after running some time.

I already have an idea ... it's about locking the resolvsem and not releasing
it in some error cases. I'll fix it ASAP (first in the CVS head) ... which will
not before tonight.

CU Andre E-Mail: ***@grueneberg.de

[Tommi Koivula]

Wednesday July 04 2012 23:12, Andre Grueneberg wrote to Tommi Koivula:

AG> That's bad news. What happened before these messages? I.e. any clue
AG> how to reproduce it? At least 0x69 means "Error, The semaphore owner
AG> has died without releasing the semaphore". So far this sounds like a
AG> generic issue in the multi-threaded version of binkd.

It tries to make a call.

05 Jul 11:11:43 [1] BEGIN, binkd/1.1a-5/OS2 -cC test1.cfg
05 Jul 11:11:43 [1] clientmgr started

05 Jul 11:19:05 [1] found old .csy file for 2:221/***@fidonet
05 Jul 11:19:05 [1] unlinked `d:\xenia\outbound\00dd0000.csy'
05 Jul 11:19:06 [1] Set MaxFH to 518 (res 6)
05 Jul 11:19:06 [1] started client #1, id=2
05 Jul 11:19:06 [2] created d:\xenia\outbound\00dd0000.csy
05 Jul 11:19:06 [2] call to 2:221/***@fidonet
05 Jul 11:19:06 [2] DosRequestMutexSem retcode 0x69
05 Jul 11:19:06 [2] exitfunc()
05 Jul 11:19:06 [1] downing clientmgr...

'Tommi

[Andre Grueneberg]

Hi Tommi

Tommi Koivula schrieb:

AG>> That's bad news. What happened before these messages? I.e. any clue
AG>> how to reproduce it? At least 0x69 means "Error, The semaphore owner
AG>> has died without releasing the semaphore". So far this sounds like a
AG>> generic issue in the multi-threaded version of binkd.
TK> It tries to make a call.
TK> 05 Jul 11:11:43 [1] clientmgr started
TK> 05 Jul 11:19:05 [1] found old .csy file for 2:221/***@fidonet 05

And between those two there has been some name resolution ...

CU Andre E-Mail: ***@grueneberg.de

[Andre Grueneberg]

Hi Tommi

Andre Grueneberg schrieb:

TK>> 05 Jul 11:11:43 [1] clientmgr started
TK>> 05 Jul 11:19:05 [1] found old .csy file for 2:221/***@fidonet 05
AG> And between those two there has been some name resolution ...

Does 1.1-a6 work any better?

CU Andre E-Mail: ***@grueneberg.de

[Tommi Koivula]

Thursday July 05 2012 22:59, Andre Grueneberg wrote to Tommi Koivula:

AG> Does 1.1-a6 work any better?

Nope, a trap!

------------------------------------------------------------

07-06-2012 09:26:32 SYS3175 PID 1394 TID 0001 Slot 01cc
D:\BINKD\CVS\ANDRE\BINKD2.EXE
c0000005
0003451c
P1=00000001 P2=00000021 P3=XXXXXXXX P4=XXXXXXXX
EAX=00000009 EBX=00000001 ECX=00000000 EDX=00000009
ESI=0016dc1c EDI=00064282
DS=0053 DSACC=f0f3 DSLIM=ffffffff
ES=0053 ESACC=f0f3 ESLIM=ffffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:0003451c CSACC=f0df CSLIM=ffffffff
SS:ESP=0053:0016dbc8 SSACC=f0f3 SSLIM=ffffffff
EBP=0016dbec FLG=00012206

BINKD2.EXE 0002:0001451c

------------------------------------------------------------

D:\binkd>help 3175

SYS3175: A program in this session encountered a problem and
cannot continue.

EXPLANATION: An access violation exception occurred and was generated
when an attempt was made either to load or store data in an inaccessible
location or to execute an inaccessible instruction. This exception
corresponds to both the Intel 80386 processor general protection fault
(#13), caused by an invalid access attempt, and the page fault (#14),
caused by an attempt to access an uncommitted page or a page with
incorrect attributes for the desired operation.

ACTION: If you purchased this program, contact the supplier of the
program. If you are the developer of this program, refer to the
information in the register.

'Tommi

[Tommi Koivula]

Thursday July 05 2012 22:59, Andre Grueneberg wrote to Tommi Koivula:

AG> Does 1.1-a6 work any better?

Congratulations, you broke the kLIBC version also: ;-)

D:\binkd>cvs\binkd\binkd2e.exe -vv

Binkd 1.1a-6 (Jul 6 2012 09:52:30/OS2)
Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm, amiga_4d_outbound,
Facilities: fsp1035 rfc2553emu

D:\binkd>cvs\binkd\binkd2e.exe -cC test1.cfg

Killed by SIGSEGV
pid=0x1b6b ppid=0x1ae5 tid=0x0001 slot=0x01dc pri=0x0200 mc=0x0001
D:\BINKD\CVS\BINKD\BINKD2E.EXE
LIBC065 0:00066c59
cs:eip=005b:1dc66c59 ss:esp=0053:0215fd70 ebp=0215fd88
ds=0053 es=0053 fs=150b gs=0000 efl=00012286
eax=00000001 ebx=b41588f8 ecx=b4158900 edx=b4158900 edi=0215fe30 esi=000297a5
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

'Tommi

[Andre Grueneberg]

Hi Tommi

Tommi Koivula schrieb:

AG>> Does 1.1-a6 work any better?
TK> Congratulations, you broke the kLIBC version also: ;-)

So I'll have to dig deeper now ... I do not yet have any idea ...

CU Andre E-Mail: ***@grueneberg.de

[Andre Grueneberg]

Hi Tommi

Andre Grueneberg schrieb:

AG>>> Does 1.1-a6 work any better?
TK>> Congratulations, you broke the kLIBC version also: ;-)
AG> So I'll have to dig deeper now ... I do not yet have any idea ...

Okay ... it's been an overly optimistic assumption about the state. I changed
the cleanup code in the name resolving function. In case of some lookup errors
the return value could have still been initialized leading to a double free().

Fixed in 1.1a-7.

CU Andre E-Mail: ***@grueneberg.de

[Tommi Koivula]

AG> Okay ... it's been an overly optimistic assumption about the state. I
AG> changed the cleanup code in the name resolving function. In case of
AG> some lookup errors the return value could have still been initialized
AG> leading to a double free().

AG> Fixed in 1.1a-7.

Sehr gut! :)

'Tommi

[Andre Grueneberg]

Hi Tommi

Tommi Koivula schrieb:

AG>> Fixed in 1.1a-7.
TK> Sehr gut! :)

I just wanted to see whether anyone is noticing. ;)

CU Andre E-Mail: ***@grueneberg.de

[Benny Pedersen]

Hello Andre!

03 Jul 2012 22:56, Andre Grueneberg wrote to All:

AG> Currently the following targets are (cross-)compiled:
AG> - Linux x64 using gcc (native)
AG> - Linux x64 using clang (native)
AG> - OS/2 using OpenWatcom 1.9
AG> - Win32 using MinGW32/GCC
QNAP Arc 32bit
QNAP Intel 32bit
QNAP Intel 64bit

dont know if arc is in 64bit use from qnap nas boxes

AG> All targets are compiled with zlib, bzlib2, proxy, bandwidth limiting,
AG> FSP1035 (SRV lookup in binkp.net) and IPv6 (where available). Embedded
AG> Perl support is currently not planned.
so i am ahead here ? :=)

AG> Upon completion the source as well as the binaries for OS/2 and Win32
AG> are published to http://binkd.grueneberg.de/.
thats usefull since this dists is the more or less complicated to get compiled,
but for gentoo/funtoo its just ebuilds, i admit i dont work on it daily but it
works what i have currently done

AG> Feel free to test those binaries, at your own risk, as usual. :)
currently not possible, since i will miss the portage checksums on them :=)

others is using tripwire

AG> I am open for improvement ideas.
me 2


Regards Benny

... there can only be one way of life, and it works :)