My X11 windows created by X-Win32 on a Windows 10 PC suddenly will not accept plain keystrokes. I have ssh sessions on linux machines, and when running gvim or xterm I get an X11 window. This has worked fine until today. In the middle of the day my X11 windows will no longer accept simple keystrokes. They will accept and respond to ctrl-key combinations.
So in gvim I can type ctrl-u, but "u" or ":" does nothing. Same in xterm, normal typing does nothing, but ctrl-u or ctrl-d is fine. Mouse actions are accepted and have the expected effect.
Exiting X-Win32 and restarting it does not fix the problem. Logging off and back on to the Windows PC does not either.
I also went through the X-config dialog boxes and reset everything to the default settings, which I believe they were at already.
Edit:
Using xev to capture events I get this when pressing any unmodified key:
KeyPress event, serial 31, synthetic NO, window 0x800001,
root 0x79, subw 0x0, time 2018524328, (112,26), root:(146,83),
state 0x0, keycode 8 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 31, synthetic NO, window 0x800001,
root 0x79, subw 0x0, time 2018524328, (112,26), root:(146,83),
state 0x0, keycode 8 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Typing "ab" into a xev window on a working X11 win server gives:
KeyPress event, serial 31, synthetic NO, window 0x400001,
root 0x111, subw 0x400002, time 1006336069, (55,41), root:(103,64),
state 0x0, keycode 8 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x400001,
root 0x111, subw 0x400002, time 1006336197, (55,41), root:(103,64),
state 0x0, keycode 8 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyPress event, serial 34, synthetic NO, window 0x400001,
root 0x111, subw 0x400002, time 1006337669, (55,41), root:(103,64),
state 0x0, keycode 19 (keysym 0x62, b), same_screen YES,
XLookupString gives 1 bytes: (62) "b"
XmbLookupString gives 1 bytes: (62) "b"
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x400001,
root 0x111, subw 0x400002, time 1006337749, (55,41), root:(103,64),
state 0x0, keycode 19 (keysym 0x62, b), same_screen YES,
XLookupString gives 1 bytes: (62) "b"
XFilterEvent returns: False
Related
I'm trying to print a help message using tabwriter:
func printHelp() {
writer := tabwriter.NewWriter(os.Stdout, 100, 8, 1, ' ', 0)
fmt.Println(writer, "uni outputs Unicode information for characters.")
fmt.Println(writer, "USAGE:")
fmt.Println(writer, " uni <input>\tOutputs Unicode info for the input.\t")
fmt.Println(writer, "\tProcesses U+xxxx sequences into the appropriate characters and treats control characters as control.\t")
fmt.Println(writer, " uni raw <input>\tOutputs Unicode info on the raw unporocessed input.\t")
fmt.Println(writer, " uni decomp <input\tOutputs the input with all characters decomposed.\t")
fmt.Println(writer, " uni comp <input>\tOutputs the input with all characters composed.\t")
fmt.Println(writer, " uni short <input>\tOutputs basic info about the input, one character per line.\t")
fmt.Println(writer, " uni rawshort <input>\tOutputs basic info about the raw unprocessed input, one character per line.\t")
fmt.Println(writer, " uni help\tPrints this help message.\t")
writer.Flush()
}
However the output both contains a significant amount of internal junk that shouldn't be printed and isn't aligning the columns correctly.
Here's what I get:
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} uni outputs Unicode information for characters.
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} USAGE:
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} uni <input> Outputs Unicode info for the input.
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} Processes U+xxxx sequences into the appropriate characters and treats control characters as control.
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} uni raw <input> Outputs Unicode info on the raw unporocessed input.
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} uni decomp <input Outputs the input with all characters decomposed.
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} uni comp <input> Outputs the input with all characters composed.
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} uni short <input> Outputs basic info about the input, one character per line.
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} uni rawshort <input> Outputs basic info about the raw unprocessed input, one character per line.
&{0xc000006018 100 8 1 [32 32 32 32 32 32 32 32] 0 [] 0 {0 0 false} 0 [[]] []} uni help Prints this help message.
and here's roughly what I want
uni outputs Unicode information for characters.
USAGE:
uni <input> Outputs Unicode info for the input.
Processes U+xxxx sequences into the appropriate characters and treats control characters as control.
uni raw <input> Outputs Unicdoe info on the raw unporocessed input.
uni decomp <input Outputs the input with all characters decomposed.
uni comp <input> Outputs the input with all characters composed.
uni short <input> Outputs basic info about the input, one character per line.
uni rawshort <input> Outputs basic info about the raw unprocessed input, one character per line.
uni help Prints this help message.
I've tried all changing the minimum cell width to all sorts of values, from 0 to multiple hundreds, and it changes the alignment but not to the point of working correctly. I've tried tab vs space separators and Right Alignment vs default (left) alignment with no differences.
To write to an io.Writer use fmt.Fprintln (or fmt.Fprintf) instead of fmt.Println:
// fmt.Println(writer, "uni outputs Unicode information for characters.")
fmt.Fprintln(writer, "uni outputs Unicode information for characters.")
fmt.Println will do its best to just render each argument - hence why you are seeing the tabwriter's internal reflected state.
This is a quiz question which I failed in the past and despite having access to the solution, I don't understand the different step to come to the correct answer.
Here is the problem :
Which of these adress is line cache aligned
a. 0x7ffc32a21164
b. 0x560c40e05350
c. 0x560c40e052c0
d. 0x560c3f2d71ff
And the solution to the problem:
Each hex char is represented by 4 bits
It takes 6 bits to represent 64 adress, since ln(64)/ln(2) = 6
0x0 0000
0x4 0100
0x8 1000
0xc 1100
________
2^3 2^2 2^1 2^0
8 4 2 1
Conclusion: if the adress ends if either 00, 40, 80 or c0, then it is aligned on 64 bytes.
The answer is c.
I really don't see how we go from 6 bits representation to this answer. Can anyone adds something to the solution given to make it clearer?
The question boils down to: Which number is a multiple of 64? All that remains is understanding the number system they're using.
In binary, 64 is written as 1000000. In hexadecimal, it's written as 0x40. So multiples of 64 will end in 0x00 (0 * 64), 0x40 (1 * 64), 0x80 (2 * 64), or 0xC0 (3 * 64). (The cycle then repeats.) Answer c is the one with the right ending.
An analogy in decimal would be: Which number is a multiple of 5? 0 * 5 is 0 and 1 * 5 is 5, after which the cycle repeats. So we just need to look at the last digit. If it's a 0 or a 5, we know the number is a multiple of 5.
i m using C to Call Fortran,
my fortran is calling sort() method
*-----------------------------------------------------------------------
* SUBROUTINE sort(A,n)
* Subroutine de la librairie "Numerical Recipes"
* (C) Copr. 1986-92 Numerical Recipes Software
*-----------------------------------------------------------------------
SUBROUTINE sort(arr,n)
INTEGER n,M,NSTACK
REAL arr(n)
PARAMETER (M=7,NSTACK=50)
INTEGER i,ir,j,jstack,k,l,istack(NSTACK)
REAL a,temp
jstack=0
l=1
ir=n
1 if(ir-l.lt.M)then
do 12 j=l+1,ir
a=arr(j)
do 11 i=j-1,1,-1
if(arr(i).le.a)goto 2
arr(i+1)=arr(i)
11 continue
i=0
2 arr(i+1)=a
12 continue
if(jstack.eq.0)return
ir=istack(jstack)
l=istack(jstack-1)
jstack=jstack-2
else
k=(l+ir)/2
temp=arr(k)
arr(k)=arr(l+1)
arr(l+1)=temp
if(arr(l+1).gt.arr(ir))then
temp=arr(l+1)
arr(l+1)=arr(ir)
arr(ir)=temp
endif
if(arr(l).gt.arr(ir))then
temp=arr(l)
arr(l)=arr(ir)
arr(ir)=temp
endif
if(arr(l+1).gt.arr(l))then
temp=arr(l+1)
arr(l+1)=arr(l)
arr(l)=temp
endif
i=l+1
j=ir
a=arr(l)
3 continue
i=i+1
if(arr(i).lt.a)goto 3
4 continue
j=j-1
if(arr(j).gt.a)goto 4
if(j.lt.i)goto 5
temp=arr(i)
arr(i)=arr(j)
arr(j)=temp
goto 3
5 arr(l)=arr(j)
arr(j)=a
jstack=jstack+2
if(jstack.gt.NSTACK)pause 'NSTACK too small in sort'
if(ir-i+1.ge.j-l)then
istack(jstack)=ir
istack(jstack-1)=i
ir=j-1
else
istack(jstack)=j-1
istack(jstack-1)=l
l=i
endif
endif
goto 1
END
And if i call sort method many times, i have a segfault in this method :(
It's legacy code but i'm trust in it because it come from numerical recipies.
But i'm suspicious about some things, in particular this line :
if(jstack.gt.NSTACK)pause 'NSTACK too small in sort'
If i'm in this case, my programm will in pause? how it's possible that a sort method do this?
And if this line is suspicious, how can i trust the entire code?
does anyone know a problem with this sort subroutine? does anybody know another method to doing sort in fortran? Because i can replace this sort method by another one but i'm new in fortran and i can't write another one.
I add that no problem if i run this method in mono thread, but if i run it in multi thread environement, problem is here. sorry to don't mentionned when i wrote my question but i see this after writing it.
DEBUG information
current thread: t#41
[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xffbffeff, 0x0), at 0xff2caa58
[2] raise(0x6, 0x0, 0xff342f18, 0xff2aa378, 0xffffffff, 0x6), at 0xff265a5c
[3] abort(0x7400, 0x1, 0x0, 0xfcb78, 0xff3413d8, 0x0), at 0xff24194c
[4] os::abort(0x1, 0x0, 0xff011084, 0xfefdc000, 0x7d94, 0x7c00), at 0xfee7d3cc
[5] VMError::report_and_die(0x0, 0xff038640, 0xff031ff4, 0x1, 0xfee81b94, 0xff031ff4), at 0xfef0cd58
[6] JVM_handle_solaris_signal(0xb, 0xacffefe0, 0xacffed28, 0x8000, 0xff030fa0, 0x2013d8), at 0xfea73d48
[7] __sighndlr(0xb, 0xacffefe0, 0xacffed28, 0xfea7325c, 0x0, 0x1), at 0xff2c6e78
---- called from signal handler with signal 11 (SIGSEGV) ------
[8] sort_(0xfe2b1350, 0xfe2b135c, 0xfe2b1000, 0x1c00, 0x443bfc7b, 0xfe292484), at 0xfe27e498
[9] mediane_(0xa9c1624c, 0xacfff2ac, 0xa9c16060, 0xa9c05c34, 0x0, 0x19), at 0xfe27a38c
(dbx) frame 8
0xfe27e498: sort_+0x01d8: ld [%l4 + %l1], %f4
(dbx) disassemble
0xff2caa58: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xff2caa68
0xff2caa5c: __lwp_kill+0x000c: clr %o0
0xff2caa60: __lwp_kill+0x0010: cmp %o0, 91
0xff2caa64: __lwp_kill+0x0014: move %icc,0x4, %o0
0xff2caa68: __lwp_kill+0x0018: retl
0xff2caa6c: __lwp_kill+0x001c: nop
0xff2caa70: __lwp_self : mov 164, %g1
0xff2caa74: __lwp_self+0x0004: ta %icc,0x00000008
0xff2caa78: __lwp_self+0x0008: retl
0xff2caa7c: __lwp_self+0x000c: nop
in m in solaris with dbx=> gdb on
i try to inspect adress but what can i type to have interesting informations?
After adding -g option to f90 compiler, in dbx i can see value or var and see the result:
t#88 (l#88) terminated by signal ABRT (Abort)
0xff2caa58: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xff2caa68
Current function is sort
578 temp=arr(k)
(dbx) print n
n = 19
(dbx) print arr
arr =
(1) 725.0666
(2) 741.5034
(3) 730.8196
(4) 754.3707
(5) 741.718
(6) 741.718
(7) 741.8914
(8) 745.9141
(9) 744.6705
(10) 741.718
(11) 745.8358
(12) 743.3788
(13) 746.2706
(14) 746.2706
(15) 750.1498
(16) 754.3707
(17) 754.3707
(18) 754.3707
(19) 748.2084
(dbx) print istack
istack =
(1) 7
(2) 12
(3) 17
(4) 18
(5) 8
(6) 9
(7) 1
(8) 4
(9) 0
(10) 0
(11) 0
(12) 0
(13) 0
(14) 0
(15) 0
(16) 0
(17) 0
(18) 0
(19) 0
(20) 0
(21) 0
(22) 0
(23) 0
(24) 0
(25) 0
(26) 0
(27) 0
(28) 0
(29) 0
(30) 0
(31) 0
(32) 0
(33) 0
(34) 0
(35) 0
(36) 0
(37) 0
(38) 0
(39) 0
(40) 0
(41) 0
(42) 0
(43) 0
(44) 0
(45) 0
(46) 0
(47) 0
(48) 0
(49) 0
(50) 0
(dbx) print jstack
jstack = -31648
(dbx)
how its possible taht jstack have a -31648 val! istack have only 50 element and istack(jstack) retrun me a abd value! how its possible? :)
thanks by advance
Too large for a comment:
Unfortunately the stack trace does not show the exact line of failure. What is the evidence that the error is at the line you indicated. I could imagine there could be error in calling the run-time system, sou you should try to change the PAUSE statement to write, read *, or something similar.
I did some tests with your subroutine in gfortran:
parameter (n = 100000)
dimension b(n)
do i=1,1000
call random_number(b)
call sort(b,n)
end do
end
with different array sizes and loop bounds. This calls the sort with many different inputs. I enabled all checks and sanitizations and didn't encounter a single problem.
Edit:
It works with OpenMP too:
parameter (n = 100000)
real,allocatable :: b(:)
!$omp parallel private(b)
allocate(b(n))
!$omp do
do i=1,1000
call random_number(b)
call sort(b,n)
end do
!$omp end do
!$omp end parallel
end
In reference to the cache question at the following link :
link
Question is : Using the the series of addresses below, show the hits and misses and final cache contents for a two-way set-associative cache with one-word blocks, 4-byte words, and a total size of 16 words. Assume FIFO replacement.
0, 4, 64, 0, 128, 32, 12, 96, 128, 64
My question is : Why is the tag value set to word address / 8 ?
Thanks.
Short explanation - If the cache holds 16 words total ( = 64 bytes cache, pretty small :), and it's 2-way set associative, then you have 8 sets that are directly mapped by the address. You don't need the set bits to be part of the tag because you've already used them to map to the correct set.
Assuming the access granularity is 1 byte, than you address has 2 LSB bits that map you inside a block (4 bytes), you need to ignore these when accessing the cache since you're reading the full block (the memory unit would then use these 2 bits to give you the exact bytes within the block according to the read size and alignment). So word address = real_address / 4
Now, since you have 8 sets, you use the next 3 bits to map to the correct set.
+--------------------------------------+----------------------+-------------------+
| Tag (bits 5 and above) | Set (bits 2,3,4) | Offset (bits 0,1) |
+--------------------------------------+----------------------+-------------------+
That is, addr 0x0 would map to set 0, addr 0x4 (word addr 0x1) would always sit at set no. 1, no matter what. set 2 would have addr 0x8 (word addr 0x2), set 3 would have addr 0xC (word addr 0x3), ... and so on , until set 7 would be used for addr 0x1C (word addr 0x7).
The next address would simply wrap - addr 0x20 (word addr 0x8) would check bits 2..4 and see they're zeroed, so would map again to set 0, and so on. At this point comes the tag to distinguish between address 0x0, addr 0x20, addr 0x10000, or any other address that maps there (addr % 0x20 == 0, or word_addr % 8 == 0). Since you don't care about the offset inside the line here, and the set bits are already known when you decide to access a given set, the only thing missing that requires storage (aside from the data of course), are the bits above the set bits - this is required (and enough) to determines the line identity in a given set, and to know if a lookup hits or misses. These bits are addr / 0x20 (or addr >> 5), or word_addr / 8 ( = word_addr >> 3)
Note that this means that a tag alone is not enough to identify the line addr, you need tag and set bits to reconstruct that.
I have mistakenly overwritten sector 1 block 7 of one of my Mifare classic 1k tags. It was meant for testing and the 16 byte data that I wrote on block 7 is shown below:
0xaa 0xaa 0xaa 0xaa
0xbb 0xbb 0xbb 0xbb
0xcc 0xcc 0xcc 0xcc
0xdd 0xdd 0xdd 0xdd
If not mistaken, by doing so, my access keys and permission bits have become as following:
Key-A: 0xaa 0xaa 0xaa 0xaa 0xbb 0xbb
Key-B: 0xcc 0xcc 0xdd 0xdd 0xdd 0xdd
Permisssion Bits: --> 0xbb 0xbb 0xcc
I have tried to use Key-A and Key-B as shown above to read/write block 7 in sector 1. But I am no longer able to access (no read or write) any block in sector 1 anymore.
I know the keys to all other sectors (e.g. sector 0 and sectors 2-15) and able to access them.
Considering the situation, I would like to know if there is any way to reset sector 1 or block 7 to regain my access. Many thanks.
Update:
I have confirmed that both Key-A and Key-B as shown above are correct and I can authenticate to the card with both of them. Also, as per the Mifare Classic specification (screenshot), my access bits are as follows:
Byte 6 = 0xbb = 0b10111011
--------------------------
C2_3 C2_2 C2_1 C2_0 C1_3 C1_2 C1_1 C1_0
1 1 0 1 1 1 0 1
Byte 7 = 0xbb = 0b10111011
--------------------------
C1_3 C1_2 C1_1 C1_0 C3_3 C3_2 C3_1 C3_0
1 1 0 1 1 1 0 1
Now, considering the specification/screenshot, C1_3, C2_3 and C3_3 bits enable read/write access to sector-trailer. In my case, for block 7 (trailer for sector 7) they are all set to 1. Should I not have write access to this block then?
Once the Access Control bits are not configured correctly (for example, bits that are supposed to be each other's complement are not complementary, like in your case), the sector cannot be accessed anymore at all.
In the Mifare classic specification you linked says:
Remark: With each memory access the internal logic verifies the format
of the access conditions. If it detects a format violation the whole
sector is irreversibly blocked.
Your access bytes does not verify the format. In the folowing table ~ means inverted
Byte 6
--------------------------
~C2_3 ~C2_2 ~C2_1 ~C2_0 ~C1_3 ~C1_2 ~C1_1 ~C1_0
1 0 1 1 1 0 1 1
Byte 7
--------------------------
C1_3 C1_2 C1_1 C1_0 ~C3_3 ~C3_2 ~C3_1 ~C3_0
1 0 1 1 1 0 1 1
Byte 8
--------------------------
C3_3 C3_2 C3_1 C3_0 C2_3 C2_2 C2_1 C2_0
1 1 0 0 1 1 0 0
So, for instance, C2_3 = 1 and ~C2_3 = 1. They are not complementary. Format not verified, sector is irreversibily blocked.
In the same document there is a table (table 7) that shows that keyA can always be readed. Maybe this is the reason you can authenticate.