Getting on my nerves
All this samba printing is crap.(Cyberpunk, 2003/07/28 18:05) lien permanent
lundi 28 juillet 2003All this samba printing is crap.(Cyberpunk, 2003/07/28 18:05) lien permanent
vendredi 25 juillet 2003FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0012D9C4 309298AD 00000491 00000000 00000000 309263CC !StdExceptionLink::StdExceptionLink 0012DAF4 3094A4C5 0000008A 0012DB0C 00000000 024D0314 !MsoFEnumComponentQualifiers 0012DB10 309D9711 0000008A 00000000 309D96F7 024D0314 !MsoPrcSetRc 0012DB7C 3041C148 0074D4A8 024D0314 00000000 0000000A !MsoFAGIF 0012DC44 300D2077 00000000 0012F768 0012FBBC 0074D4A8 !wdCommandDispatch 0012DC68 300BC510 00000000 0012F768 0012DCF0 0013477C !<nosymbols> 0012DCD0 300BBF55 00000000 0012F768 0074D4A8 0012FC34 !<nosymbols> 0012F78C 300BBDEB 00000001 00000001 0012FA54 00000000 !<nosymbols> 0012FC48 3031E74E 00000001 0074D4A8 00000000 00000001 !<nosymbols> 0012FC78 300E2201 0012FCE0 00000000 3013C9F0 0012FCE0 !wdCommandDispatch 0012FCC0 300FE730 0012FCE0 00000001 00000000 00000400 !<nosymbols> 0012FD3C 3027234A 00000348 0000025A 000000FF 00000002 !<nosymbols> 00000000 00000000 00000000 00000000 00000000 00000000 !wdCommandDispatch
(Cyberpunk, 2003/07/25 05:54) lien permanent
mardi 15 juillet 2003Strange result, I perhaps have missed the point in the documentation. But here is the thing, while multithreaded, even if not in concurrent access, jclass as returned by FindClass are not valid call after call, while jmethodID as returned by GetMethodID are. On Solaris, a new instance created with a wrong jclass leads to this:
Unexpected Signal : 10 occurred at PC=0xfe51e010 Function name=JVM_NewInstance Library=/opt/WebSphere/AppServer/java/jre/lib/sparc/client/libjvm.so # # HotSpot Virtual Machine Error : 10 # Error ID : 4F530E43505002BD 01 # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.3.1_05-b02 mixed mode) # # An error report file has been saved as hs_err_pid20077.log. # Please refer to the file for further information. #
and this (dump trace):
f4480080 libthread.so.1`__sigprocmask+8(ff36bf18, 0, 0, f4481d70, ff37e000, 0)
f4480120 libthread.so.1`_sigon+0xd0(f4481d70, ff385938, 6, f44801e4, f4481d70, 6)
f4480180 libthread.so.1`_thrp_kill+0xf8(0, 11, 6, ff37e000, 11, ff2bc488)
f44801e8 libc.so.1`raise+0x40(6, 0, 0, ffffffff, ff2bc3f4, 4)
f4480248 libc.so.1`abort+0x100(ff2b801c, f4480338, 0, fffffff8, 4, f4480359)
f44802d8 libjvm.so`__1cCosFabort6Fl_v_+0xb8(1, fe742000, 1, f44803b8, 0, fe51e010)
f4480358 libjvm.so`__1cCosbBhandle_unexpected_exception6FpnGThread_ipCpv_v_+0x254(ff2bc2e4, fe77efe8, \
fe754d58, fe704a70, fe742000, f44803d8)
f4480c08 libjvm.so`JVM_handle_solaris_signal+0x894(0, 2469e8, f4480e60, fe742000, a, f4481118)
f4480cc8 libthread.so.1`__sighndlr+0xc(a, f4481118, f4480e60, fe6865fc, f4481e14, f4481e04)
f4480d28 libthread.so.1`sigacthandler+0x708(a, f4481d70, 0, 0, 0, ff37e000)
f4481198 libjvm.so`__1cMalloc_object6FpnH_jclass_pnGThread__pnPinstanceOopDesc__+0x7c(1, 2469e8, \
f44819b8, ff284bb4, f4480d8c, 0)
f4481200 libjvm.so`jni_NewObject+0x78(246a74, 249528, fe742000, 2469e8, fafa2998, fe742000)
f4481298 libmylib.so`myCFunction+0x134(246a74, f4481558, f4481390, f4481380, fffffff8, f4481558)
f4481310 libmylib.so`Java_com_my_class_myMethod+0x5a4(246a74, f44817b4, f44817b0, f44817ac, f44817a8, f44817a4)
(Cyberpunk, 2003/07/15 05:41) lien permanent
mardi 8 juillet 2003As promised, a code sample showing the behaviour of wait() and notify(). Several of them exist already on the net, but sometimes, if you don't look by yourself, you don't understand. The code is a bit long (90 lines).
package sandbox;
public class TimeOut implements Runnable {
private boolean forceStop;
private int timeToRun;
private boolean finished;
public TimeOut() {
forceStop = false;
finished = false;
}
public void demo(int p_timeToWait, int p_timeToRun) {
timeToRun = p_timeToRun;
Thread t = new Thread(this);
forceStop = false;
finished = false;
t.start();
try {
synchronized(t) {
trace("Monitor acquired");
t.wait(p_timeToWait);
trace("Monitor re-acquired");
}
} catch (InterruptedException ie) {
trace("Interrupted while waiting for time-out");
}
if (t.isAlive() && !finished) {
trace("Time out!");
forceStop = true;
try {
trace("Waiting for effective end of work");
t.join();
trace("End of work reached");
} catch (InterruptedException ie) {
trace("Interrupted while waiting for effective end of work");
}
}
}
public void run() {
trace("Starting to work");
// détermination du port
for(int i = 0; i < 10 && !forceStop; ++i) {
try {
Thread.sleep(timeToRun / 10);
trace("Working...");
} catch (InterruptedException ie) {
trace("Interrupted");
}
}
int remaining = timeToRun - (timeToRun / 10) * 10;
if(remaining > 0) {
try {
Thread.sleep(remaining);
} catch (InterruptedException ie) {
trace("Interrupted remaining");
}
}
finished = true;
if(!forceStop) {
forceStop = false;
trace("Notifying end of work");
synchronized (Thread.currentThread()) {
Thread.currentThread().notify();
}
}
trace("End of work");
}
private static void trace(String s) {
System.out.println(System.currentTimeMillis()+": "+s);
}
public static void main(String[] argv) {
TimeOut to = new TimeOut();
trace("Demo 15, 20");
to.demo(15, 20);
trace("===");
trace("Demo 20, 15");
to.demo(20, 15);
}
}
A remark, the test "t.isAlive()" is not sufficient, because there is no guarantee that run() finishes before wait() is released. Here is a sample output:
javaw.exe -classpath . sandbox.TimeOut 1057702792318: Demo 15, 20 1057702792318: Monitor acquired 1057702792318: Starting to work 1057702792318: Working... 1057702792318: Working... 1057702792318: Working... 1057702792328: Working... 1057702792328: Working... 1057702792328: Working... 1057702792328: Monitor re-acquired 1057702792328: Time out! 1057702792328: Waiting for effective end of work 1057702792328: Working... 1057702792328: End of work 1057702792328: End of work reached 1057702792328: === 1057702792328: Demo 20, 15 1057702792328: Monitor acquired 1057702792328: Starting to work 1057702792338: Working... 1057702792338: Working... 1057702792338: Working... 1057702792338: Working... 1057702792338: Working... 1057702792338: Working... 1057702792338: Working... 1057702792338: Working... 1057702792338: Working... 1057702792338: Working... 1057702792348: Notifying end of work 1057702792348: End of work 1057702792348: Monitor re-acquired
Enjoy!(Cyberpunk, 2003/07/08 18:26) lien permanent
From SUN's java.lang.Object Javadoc:
- wait
- Causes current thread to wait until either another thread invokes the notify() method or the notifyAll() method for this object, or a specified amount of time has elapsed. The current thread must own this object's monitor.
- notify
- This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways: * By executing a synchronized instance method of that object. * By executing the body of a synchronized statement that synchronizes on the object. * For objects of type Class, by executing a synchronized static method of that class. Only one thread at a time can own an object's monitor.
- notifyAll
- Wakes up all threads that are waiting on this object's monitor. A thread waits on an object's monitor by calling one of the wait methods. This method should only be called by a thread that is the owner of this object's monitor.
So, in order to call wait(), I must have the object monitor... but at that moment my thread is blocked, so I can't release the monitor, so nobody can call notify() or notifyAll() on my object. What am I missing?
Update: I've something working, I'm still not sure why it works, I'll post the code later this evening
Update 2: as Chris Nokleberg mentionned, the monitor on the object is lost when wait is called, and this is written in the Javadoc... lost between other things. By the way, the description of wait(), wait(long) and wait(long, int) should be homogenous...(Cyberpunk, 2003/07/08 11:01) lien permanent
As soon as you wait, the monitor is released.
Posté par Chris Nokleberg, le mardi 8 juillet 2003 à 10:43 #
Ok, that's a bit confusing, since I'm still in a synchronised block for instance.
Well, it appears that one must read all three wait() Javadoc description to get the full picture.
Giving wait() magical monitor releasing powers has always looked like a hack to me. On the plus side, this kind of threading is not something that we have to worry about very often.
Here's some more general notes about threading: http://www.cardboard.nu/archives/000047.html
Posté par Alan Green, le mardi 8 juillet 2003 à 19:29 #
mardi 1 juillet 2003Chiara said:
L/GPL'ed license. you have to contribute back to if you fix something or modify code.
Sorry Chiara but it's false 
From the GPL FAQ:
The GPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.
The GPL requires that if someone gets legally a binary of a GPL product, he/she can get the source code of the application for a fee covering the expenses of reproduction, from the people/organization who made the build. With the source code, he/she can do what he/she wants in the limit of the GPL (you can't put further restrictions) and the copyright laws.
The viral aspect is a different part. That's why I think they should do a LGPL FAQ.
(Cyberpunk, 2003/07/01 18:59) lien permanent wow. thanks Damien.. some reason, this sounded crystal clear.. I got it, i got it, by jove, i got..
but, i can see why Apache folks would stay away from this.. hmm, the software company who mixes opensource L/GPL'ed code with their stuff is liable to release it later on, that's why those apache guys hate this license. well, at least the consultants who use opensource ones when they work with their client and the client doesn't ever want it to be released for competitive reasons..i know some cases of this happening.
That's where LGPL could be useful if the conditions of application weren't so obscure. In my case, I wouldn't not hesitate too long to propose GPL code to our customer, because I almost only work for in-house systems, and even if the code is great, the code is so specific that the company, even if if was interested in software distribution, which is never the case, would never bother to sell a binary form of the code. Most of the time, the code is the implementation of their business process, so neither a binary nor the source should go out, thus GPL is fine
I can't put a screenshot because the M$Word document is under a NDA, but I've a graph in it, and when I select the text inside a text box, this is repeated in two others text boxes, where it has replaced the original text... Yes, my selection is reproduced two other times on the screen, and I've three texts selected at the same time. And of course, some information has been lost, thanks M$. It's unbelievable how crappy it is.
Update 15:08 (minus the time difference with the freeroller.net server), I should have foreseen it:
État de vidage Thread Id 0x444
eax=309263cc ebx=00000024 ecx=00000024 edx=00000000 esi=00000000 edi=309263cc
eip=30926baa esp=0012d990 ebp=0012d9c4 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
fonction : StdExceptionLink::StdExceptionLink
30926b97 83664400 and dword ptr [esi+0x44],0x0 ds:00a8d5d2=00000000
30926b9b 8930 mov [eax],esi ds:309263cc=00000001
30926b9d 894e40 mov [esi+0x40],ecx ds:00a8d5d2=00000000
30926ba0 8bc6 mov eax,esi
30926ba2 5e pop esi
30926ba3 c3 ret
30926ba4 53 push ebx
30926ba5 56 push esi
30926ba6 33f6 xor esi,esi
30926ba8 33d2 xor edx,edx
FAUTE ->30926baa 668b31 mov si,[ecx] ds:00000024=????
30926bad 57 push edi
30926bae 85f6 test esi,esi
30926bb0 742d jz MsoInitImm2+0x2ab (3092f6df)
30926bb2 8b790c mov edi,[ecx+0xc] ds:00a8d5f6=00000000
30926bb5 8b5c2410 mov ebx,[esp+0x10] ss:00bbaf63=????????
30926bb9 eb07 jmp MsoInitImm2+0x48e (3092f8c2)
30926bbb 8d5001 lea edx,[eax+0x1] ds:313b399e=????????
30926bbe 3bd6 cmp edx,esi
30926bc0 741d jz MsoInitImm2+0x2ab (3092f6df)
30926bc2 8bc6 mov eax,esi
30926bc4 2bc2 sub eax,edx
*----> Parcours arrière de la pile <----*
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0012D9C4 309298AD 00000491 00000000 00000000 309263CC !StdExceptionLink::StdExceptionLink
0012DAF4 3094A4C5 0000008A 0012DB0C 00000000 024D0F14 !MsoFEnumComponentQualifiers
0012DB10 309D9711 0000008A 00000000 309D96F7 024D0F14 !MsoPrcSetRc
0012DB7C 3041C148 0074D404 024D0F14 00000000 00000016 !MsoFAGIF
0012DC44 300D2077 00000000 0012F768 0012FBBC 0074D404 !wdCommandDispatch
0012DC68 300BC510 00000000 0012F768 0012DCF0 00134794 !<nosymbols>
0012DCD0 300BBF55 00000000 0012F768 0074D404 0012FC34 !<nosymbols>
0012F78C 300BBDEB 00000001 00000001 0012FA54 00000000 !<nosymbols>
0012FC48 3031E74E 00000001 0074D404 00000000 00000001 !<nosymbols>
0012FC78 300E2201 0012FCE0 00000000 3013C9F0 0012FCE0 !wdCommandDispatch
0012FCC0 300FE730 0012FCE0 00000001 00000000 00000400 !<nosymbols>
0012FD3C 3027234A 00000348 0000025A 000000FF 00000002 !<nosymbols>
00000000 00000000 00000000 00000000 00000000 00000000 !wdCommandDispatch
(Cyberpunk, 2003/07/01 09:16) lien permanent
![[]](http://m3.moostik.net/img/?pseudo=kame&cpt=NuAccueil&option=invisible)
apparemment, rien n'a changé depuis que je suis en vacances.......
word plante toujours autant!!
:p
Posté par diabolo512, le mardi 29 juillet 2003 à 17:24 #