Giải thích nguyên nhân về bug dupe gold. Blizzard programmer lại fucked up 1 lần nữa =)

_ Chơi integer làm quái gì phải chơi unsigned integer mới đúng, dm thằng lập trình lười tới mức phải dùng integer để hạn chế gold up lên mà ko lường được hậu quả :-B Sau vụ này khối thẳng ra đi, khối thằng trừ lương, khối thằng viết kiểm điểm =))
 
unsigned thì đỡ hơn 1 chút nhưng cũng vậy thôi: treo 10 tỷ, mất 4 tỷ cancel được bù lại 6 tỷ.

Đụng tới tiền là phải xài số nguyên 64 bit (long) thì mới được. Cái AH này chạy trên PC thì đâu có thiếu memory để phải hà tiện tới mức chỉ xài 32 bit, bó tay.
 
dev thì cũng là người mà, lúc nào chẳng có sơ xuất được. Có điều hậu quả thế nào thôi :)). Cái lỗi này trong trading system của công ty mình bị một phát rồi nhưng phát hiện sớm không gây hiệu quả gì. Mà là trading system của top tier investment bank đó :)). có điều cái app khác nó catch lỗi này :))
 
Bài giải thích đầu topic là chưa chính xác.

Tôi mới coi được video dup gold. Nhìn video thì thấy treo 6 tỷ, lên AH 1.7 tỷ (6 tỷ - 2^32). Như vậy AH xài biến unsigned int 32 bit để lưu số tiền chứ ko phải signed int.

Ku đó treo 6 tỷ, do AH chỉ hiểu 4.3 tỷ nên sẽ bị tràn số và quay vòng về 1.7 tỷ. Do đó acc chỉ bị trừ đi 1.7 tỷ thôi. Sau đó, khi hắn cancel thì được bù lại đủ 6 tỷ.

http://www.youtube.com/watch?v=Xe28jcTsdU8

Có 1 sự chênh lệch nhỏ giữa con số treo lên và con số sau khi cancel (dù cả 2 đều là ~1.7 tỷ) là do vài triệu gold đã được người khác mua mất.

Thêm 1 điều nữa, là trước cái fix AH có thể hiểu tối đa 4.29 tỷ (2^32) chứ không phải chỉ 2 tỷ. Con số 2 tỷ không phải từ giới hạn của biến.
 
Chỉnh sửa cuối:
Nghe sao giống film hài vậy trời, chơi luôn long int ngay từ đầu thì.... Không thể hiểu đc.
 
* Cái này thì chắc mấy ông nào lập trình cho các ngân hàng, hoặc nói chung là lập trình liên quan đến cái gì mà phải xử lý những con số lớn mới gặp, chứ lập trình bt cũng ít khi gặp phải mấy cái này. Nhưng mà chốt lại là làm cái gì mà liên quan đến tiền bạc thật cũng đều nguy hiểm, có sơ sót gì đó thì hậu quả khó lường

* Ví dụ 1 công ty mà sử dụng phần mềm tính toán số liệu, tiền bạc, thống kê mà phần mềm bị sai thì ... tèn ten :D

- - - Updated - - -



Mở rộng số lượng gold cho 1 stack lên đến 10 tỷ, nhưng mà chắc là ko thèm test lại, vì cứ nghĩ la treo bình thường, chứ cái test treo/cancel đơn giản như vậy làm gì chẳng phát hiện ra bug =))

code 1 cái trading platform như AH đâu phải đơn giản, đã làm thì phải làm cho đến chốn. Cash flow liên tục với số lượng lớn như thế mà tầm nhìn Blizzard hạn hẹp chỉ hire những thằng programmer gà mờ kiểu thế thì ko có lời gì để nói :(

- - - Updated - - -

chuyển lại 1 lần bán max 2bil, giảm giá bán xuống 0.025$, ko lẽ blizz nó chê số bé quá ăn tiền chả bõ hay sao nhỉ :))

tốt nhất là đổi, programmer phải lường trước cái này. Thời buổi này xài LONG thay cho INT có mất bao nhiêu phần ổ cứng nữa đâu ...
mà cũng ko cần phải đổi, chỉ cần nhớ là xài INT thì handle số lớn hơn 2^31 thì phải test kĩ càng thôi.
 
Em nghĩ nó ko mắc phải lổi sơ đẳng lập trình mà do làm ăn cẩu thả ko test lại. Bằng chứng là server EU ko bị dupe. Team US làm ăn như shit ấy. Xa thải hết là vừa.
 
Bài giải thích đầu topic là chưa chính xác.

Tôi mới coi được video dup gold. Nhìn video thì thấy treo 6 tỷ, lên AH 1.7 tỷ (6 tỷ - 2^32). Như vậy AH xài biến unsigned int 32 bit để lưu số tiền chứ ko phải signed int.

Ku đó treo 6 tỷ, do AH chỉ hiểu 4.3 tỷ nên sẽ bị tràn số và quay vòng về 1.7 tỷ. Do đó acc chỉ bị trừ đi 1.7 tỷ thôi. Sau đó, khi hắn cancel thì được bù lại đủ 6 tỷ.

http://www.youtube.com/watch?v=Xe28jcTsdU8

Có 1 sự chênh lệch nhỏ giữa con số treo lên và con số sau khi cancel (dù cả 2 đều là ~1.7 tỷ) là do vài triệu gold đã được người khác mua mất.

Thêm 1 điều nữa, là trước cái fix AH có thể hiểu tối đa 4.29 tỷ (2^32) chứ không phải chỉ 2 tỷ. Con số 2 tỷ không phải từ giới hạn của biến.

oh ko rành lắm là 2 tỉ hay 4 tí, ko chơi cũng chả test nên ko biết. nói chung là xài int hay unsigned int cũng vậy thôi, cái này phải xài biến LONG, chứ 2^31 hay 2^32 chả giải quyết dc vd gì.
 
Chỉnh sửa cuối:
Sao nó lại phạm sai lầm căn bản thế nhỉ, đặt biến phải lường trước giá trị căn bản và các biến phụ thuộc, chứ không xảy ra bug dây chuyền thì có mà ăn cho hết à. Với lại không viết kèm theo cái exception để quăng lỗi ra à, có lỗi phải roll back transaction lại chứ.

_ Chơi integer làm quái gì phải chơi unsigned integer mới đúng, dm thằng lập trình lười tới mức phải dùng integer để hạn chế gold up lên mà ko lường được hậu quả :-B Sau vụ này khối thẳng ra đi, khối thằng trừ lương, khối thằng viết kiểm điểm =))

code 1 cái trading platform như AH đâu phải đơn giản, đã làm thì phải làm cho đến chốn. Cash flow liên tục với số lượng lớn như thế mà tầm nhìn Blizzard hạn hẹp chỉ hire những thằng programmer gà mờ kiểu thế thì ko có lời gì để nói :(

- - - Updated - - -



tốt nhất là đổi, programmer phải lường trước cái này. Thời buổi này xài LONG thay cho INT có mất bao nhiêu phần ổ cứng nữa đâu ...
mà cũng ko cần phải đổi, chỉ cần nhớ là xài INT thì handle số lớn hơn 2^31 thì phải test kĩ càng thôi.
Hic big data mà cứ lưu bừa mà ko dùng hết thì tại bạn ko tưởng dữ liệu nó lớn ntn thôi :D
1 công ty tin học bình thường (crawler dữ liệu người dùng = log) mà đã lên đến 3TB/ngày :D
Tất cả là do unittest và test design ko lường được đến ảnh hưởng của hệ thống mà nghiêm trọng nhất là UT như sh!t
p/s: thú thật trước mình cũng bị 1 lần :)))))
 
Hóa ra gold đặt biến là integer, công ty lớn như Blizz lại thiếu kinh nghiệm vậy sao :))
 
Hic big data mà cứ lưu bừa mà ko dùng hết thì tại bạn ko tưởng dữ liệu nó lớn ntn thôi :D
1 công ty tin học bình thường (crawler dữ liệu người dùng = log) mà đã lên đến 3TB/ngày :D
Tất cả là do unittest và test design ko lường được đến ảnh hưởng của hệ thống mà nghiêm trọng nhất là UT như sh!t
p/s: thú thật trước mình cũng bị 1 lần :)))))
Lỗi ở đây là do một biến tạm trong quá trình tính toán. Chứ số gold trong transaction (và account) thì ngon lành (chắc là biến 64 bit) nên lúc cancel mới được cộng lại 6 tỷ. Mà biến tạm đó thì không chiếm database, cái transaction (và account) mới chiếm, do Blizzard lưu lại hết transaction.
 
Chỉnh sửa cuối:
Hic big data mà cứ lưu bừa mà ko dùng hết thì tại bạn ko tưởng dữ liệu nó lớn ntn thôi :D
1 công ty tin học bình thường (crawler dữ liệu người dùng = log) mà đã lên đến 3TB/ngày :D
Tất cả là do unittest và test design ko lường được đến ảnh hưởng của hệ thống mà nghiêm trọng nhất là UT như sh!t
p/s: thú thật trước mình cũng bị 1 lần :)))))

thay giá trị 1 cái filed trong data base thôi chứ có phải cả log của toàn bộ user đâu mà bảo tốn nhiều :P
 
Back
Top