Hello,

...

Two bugs left before 7.6. The mast-thread-bug and a serious optimization bug that turns string x(string i) { return i; }; return x("")+1+1; into "2".

Personnaly I have bugs with FreeBSD regarding process.create_process as show in the Pike farm (http://pike.ida.liu.se/generated/pikefarm/7.6/17_14/verifylog.txt). It would be good if *BSD can be green.

This bug has been for ages on 7.5 tree... But I really agree that *BSD should be green...

/Xavier

-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects

Le 5 mai 04, à 13:15, Martin Nilsson (räfsfiskal) @ Pike (-) developers forum a écrit :

If it was easy to fix we would have. It appears to me that BSD is as complicated to get code to work on as for Windows, but with a much smaller user base.

I agree that *BSD is much smaller user base. But keep that broken because it is a much smaller user base, is a bit nonsence ... Because I can say exactly the same for AIX and OSF1...

So, just tell us how we can help you, ask for shell or even jail access (eg chroot access like) and we will be please to give you access...

/Xavier

-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects

I agree that *BSD is much smaller user base. But keep that broken because it is a much smaller user base, is a bit nonsence ...

Did I really say that? How strange of me...

Just by being in xenofarm has made the BSD version of Pike much improved. The best way to fix Pike for BSD is of course to find a developer who uses BSD and is willing to develop on Pike.

/ Martin Nilsson (räfsfiskal)

Previous text:

2004-05-05 14:00: Subject: Re: 7.6

---

Le 5 mai 04, à 13:15, Martin Nilsson (räfsfiskal) @ Pike (-) developers forum a écrit :

...

If it was easy to fix we would have. It appears to me that BSD is as complicated to get code to work on as for Windows, but with a much smaller user base.

I agree that *BSD is much smaller user base. But keep that broken because it is a much smaller user base, is a bit nonsence ... Because I can say exactly the same for AIX and OSF1...

So, just tell us how we can help you, ask for shell or even jail access (eg chroot access like) and we will be please to give you access...

/Xavier

-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects

/ Brevbäraren

It's actually green in 7.6 as well.

/ Martin Nilsson (räfsfiskal)

Previous text:

2004-05-05 14:41: Subject: Re: 7.6

---

...

Just by being in xenofarm has made the BSD version of Pike much improved. The best way to fix Pike for BSD is of course to find a developer who uses BSD and is willing to develop on Pike.

Personally I don't know BSD internals enought. I think this bug has been fixed in Pike 7.7 since my machine is green in the Pikefarm of 7.7. Does someone knows which changes where made for that to happen and if he can backport it ?

/ David

/ Brevbäraren

In the last episode (May 05), David Gourdelier said:

Personnaly I have bugs with FreeBSD regarding process.create_process as show in the Pike farm (http://pike.ida.liu.se/generated/pikefarm/7.6/17_14/verifylog.txt). It

This is a rare (on my system at least) problem that I have not been able to diagnose, and it has been around for ages. I usually get an error of 19 (ENODEV), and nowhere in the kernel is that error returned in the read() codepath. I even added a panic-check to the read syscall. My best guess is that the threads code is somehow corrupting errno or the returnvalue of read() during thread switches. I have only seen this with libc_r threading.

would be good if *BSD can be green. I also have this problem:

/home/david/Pike/7.6/src/threads.c:69: Fatal error: /home/david/Pike/7.6/src/signal_handler.c:1255: pthread_mutex_unlock(&wait_thread_mutex) Unexpected error from thread function: 22 Backtrace at time of fatal: object(src/module.c:61).Builtin()->create_process:

I see this too, more frequently, only with kernel threads (both libthr and libkse, iirc). 22 is EINVAL, and is returned when pthread_mutex_unlock is passed an uninitialized mutex. I've narrowed it down to a problem creating the wait thread created when pike wants to fork(). If the process is not already threaded, the th_atfork call at the top of wait_thread() initializes the parent and child callbacks but not the prepare callback (aka do_da_lock). do_da_lock locks the above mutex, and if it's not called, the child errors out trying to unlock it. If the pike script has already created threads, the call seems to work.