LINUX.ORG.RU

Сообщения Nietzsche

 

Проблемы с текстолитом в видеокарте

Перестала работать видюшка, сдал её в СЦ. Через неделю перезвонили и сказали, что сгорел чип, нужно менять. Цена замены чипа соразмерима с б/у'шной моделью этой видеокарты, но они дают гарантию несколько месяцев после ремонта, в отличии от продавцов на интеренет аукционах, поэтому я согласился. Прошла еще одна неделя. Звонок из СЦ: замена чипа ни к чему не привела, оказалось, что «проблемы с текстолитом» и это не поддается ремонту, приезжайте, забирайте.

Я понятия не имею, что такое «проблемы с текстолитом». Карта надежно сидела в системном блоке, не вынималась, не ронялась, не обливалась жидкостями, не перегревалась - ~75 градусов в нагрузке во время стресс-тестов (при допустмых 95). Гарантия истекла буквально 2 месяца назад. Около месяца назад стал крашиться видеодрайвер после ~5 минут нагрузки (как на линуксе, так и на оффтопе), при этом температура была в пределах нормы.

Предсмертная речь:

[ 7664.597685] NVRM: GPU at PCI:0000:01:00: GPU-7a6ad0f4-fac5-d459-e237-9c2a4443751e
[ 7664.597689] NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.

[ 7664.597690] NVRM: GPU at 0000:01:00.0 has fallen off the bus.
[ 7664.598127] NVRM: A GPU crash dump has been created. If possible, please run
               NVRM: nvidia-bug-report.sh as root to collect this data before
               NVRM: the NVIDIA kernel module is unloaded.
[ 8197.769382] BUG: unable to handle kernel NULL pointer dereference at 0000000000000160
[ 8197.769424] IP: [<ffffffffa1682f56>] _nv015951rm+0x1c6/0x2b0 [nvidia]
[ 8197.769634] PGD 0 

[ 8197.769642] Oops: 0000 [#1] SMP
[ 8197.769651] Modules linked in: nvidia_uvm(PO) nvidia(PO) snd_hda_codec_realtek snd_hda_codec_generic thermal battery input_leds xpad joydev ff_memless acpi_cpufreq processor x86_pkg_temp_thermal kvm_intel btusb btrtl kvm btbcm btintel irqbypass pcspkr snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep i2c_i801 snd_pcm e1000e snd_timer fan i2c_smbus snd i915 video button i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm backlight xts gf128mul aes_x86_64 cbc sha512_generic sha1_generic libiscsi scsi_transport_iscsi ixgb ixgbe dca tulip cxgb3 cxgb mdio macvlan tg3 libphy sky2 pcnet32 e1000 bnx2 fuse nfs lockd grace sunrpc jfs multipath raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash
[ 8197.770086]  dm_log dm_mod hid_sunplus hid_sony hid_samsung hid_pl hid_petalynx hid_gyration hid_apple sl811_hcd ohci_pci ohci_hcd uhci_hcd usb_storage aic94xx libsas lpfc crc_t10dif crct10dif_common qla2xxx megaraid_sas megaraid_mbox megaraid_mm megaraid aacraid sx8 DAC960 cciss 3w_9xxx 3w_xxxx mptsas scsi_transport_sas mptfc scsi_transport_fc mptspi mptscsih mptbase atp870u dc395x qla1280 imm parport dmx3191d sym53c8xx gdth initio BusLogic arcmsr aic7xxx aic79xx scsi_transport_spi sg pdc_adma sata_inic162x sata_mv ata_piix sata_qstor sata_vsc sata_uli sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil24 sata_sil sata_promise pata_sl82c105 pata_via pata_jmicron pata_marvell pata_sis pata_netcell pata_pdc202xx_old pata_triflex pata_atiixp pata_opti pata_amd pata_ali pata_it8213 pata_pcmcia pcmcia
[ 8197.770509]  pcmcia_core pata_ns87415 pata_ns87410 pata_serverworks pata_artop pata_it821x pata_optidma pata_hpt3x2n pata_hpt3x3 pata_hpt37x pata_hpt366 pata_cmd64x pata_efar pata_rz1000 pata_sil680 pata_radisys pata_pdc2027x pata_mpiix led_class usbhid ahci libahci xhci_pci ehci_pci r8169 xhci_hcd ehci_hcd mii libata ptp usbcore pps_core usb_common
[ 8197.770690] CPU: 2 PID: 16959 Comm: gpu_test Tainted: P           O    4.9.16-gentoo #1
[ 8197.770722] Hardware name: ASUS All Series/SABERTOOTH Z87, BIOS 2103 08/18/2014
[ 8197.770751] task: ffff88080f0d4bc0 task.stack: ffffc90000908000
[ 8197.770773] RIP: 0010:[<ffffffffa1682f56>]  [<ffffffffa1682f56>] _nv015951rm+0x1c6/0x2b0 [nvidia]
[ 8197.770981] RSP: 0000:ffffc9000090ba20  EFLAGS: 00010246
[ 8197.771000] RAX: 0000000000000000 RBX: ffff88080dd42f60 RCX: 00000000bf369fff
[ 8197.771028] RDX: 00000000bf369000 RSI: 0000000000000000 RDI: ffff88080e158008
[ 8197.771056] RBP: ffff88080dd42f28 R08: 0000000000000000 R09: 0000000000000001
[ 8197.771083] R10: 0000000002020008 R11: ffffffffa187d740 R12: ffff88080e158008
[ 8197.771111] R13: 0000000000000001 R14: 00000000bf369000 R15: 0000000000001000
[ 8197.771139] FS:  0000000000000000(0000) GS:ffff88082fa80000(0000) knlGS:0000000000000000
[ 8197.771170] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8197.771192] CR2: 0000000000000160 CR3: 0000000001807000 CR4: 00000000001406e0
[ 8197.771218] Stack:
[ 8197.771223]  0000000000000000 00000000000bf369 ffff88080e4ae008 ffff88080dd430b8
[ 8197.771257]  0000000000000000 ffffffffa15ce0b0 ffff88080e4ae008 00000000000bf369
[ 8197.771290]  0000000000000000 ffff88080dd430b8 ffff880803deda08 ffffffffa1870ded
[ 8197.771323] Call Trace:
[ 8197.771476]  [<ffffffffa15ce0b0>] ? _nv010389rm+0xb0/0x270 [nvidia]
[ 8197.771619]  [<ffffffffa1870ded>] ? _nv016944rm+0x6bd/0x700 [nvidia]
[ 8197.771763]  [<ffffffffa18713b0>] ? _nv016990rm+0x20/0xc0 [nvidia]
[ 8197.771893]  [<ffffffffa18e1090>] ? rm_gpu_ops_stop_channel+0x120/0x140 [nvidia]
[ 8197.772021]  [<ffffffffa1329a4c>] ? nvUvmInterfaceStopChannel+0x2c/0x3d [nvidia]
[ 8197.772058]  [<ffffffffa0d7539f>] ? uvm_user_channel_stop+0x2f/0x40 [nvidia_uvm]
[ 8197.772092]  [<ffffffffa0d4c8fa>] ? uvm_procfs_get_gpu_base_dir+0x54a/0x590 [nvidia_uvm]
[ 8197.772128]  [<ffffffffa0d4db91>] ? uvm_va_space_destroy+0x361/0x370 [nvidia_uvm]
[ 8197.772162]  [<ffffffffa0d443fc>] ? gmmuFmtInitPteCompTags+0x22c/0x1ab0 [nvidia_uvm]
[ 8197.772193]  [<ffffffff810ff3b3>] ? __fput+0xed/0x19f
[ 8197.772212]  [<ffffffff810ff491>] ? ____fput+0x9/0xb
[ 8197.772231]  [<ffffffff810583ee>] ? task_work_run+0x67/0x7f
[ 8197.772252]  [<ffffffff810457b6>] ? do_exit+0x3cb/0x87b
[ 8197.772272]  [<ffffffff8105eda1>] ? try_to_wake_up+0x20b/0x21d
[ 8197.772294]  [<ffffffff810467f9>] ? do_group_exit+0x3f/0x96
[ 8197.772316]  [<ffffffff8104e13d>] ? get_signal+0x44a/0x476
[ 8197.772337]  [<ffffffff81063539>] ? update_curr+0x64/0x8e
[ 8197.772358]  [<ffffffff81014d50>] ? do_signal+0x23/0x556
[ 8197.772378]  [<ffffffff8106957f>] ? pick_next_task_fair+0xff/0x74a
[ 8197.772401]  [<ffffffff8106957f>] ? pick_next_task_fair+0xff/0x74a
[ 8197.772425]  [<ffffffff81001034>] ? exit_to_usermode_loop+0x34/0x70
[ 8197.772450]  [<ffffffff8100138b>] ? syscall_return_slowpath+0x3e/0x51
[ 8197.772475]  [<ffffffff8157bb9f>] ? entry_SYSCALL_64_fastpath+0x92/0x94
[ 8197.772500] Code: 0f 00 00 00 0f 84 d4 fe ff ff 48 8b 83 88 00 00 00 45 31 c0 48 85 c0 0f 85 c2 00 00 00 4c 89 f2 4b 8d 4c 3e ff 4c 89 c6 4c 89 e7 <41> ff 90 60 01 00 00 84 c0 8b 43 08 0f 94 c2 a9 00 00 00 01 0f 
[ 8197.772661] RIP  [<ffffffffa1682f56>] _nv015951rm+0x1c6/0x2b0 [nvidia]
[ 8197.772857]  RSP <ffffc9000090ba20>
[ 8197.772868] CR2: 0000000000000160
[ 8197.794187] ---[ end trace 27767bb7d123d569 ]---
[ 8197.794188] Fixing recursive fault but reboot is needed!

После этого видеокарта пропала из lspci...

Что это могло быть? И что такое «проблемы с текстолитом» и почему это нельзя исправить?

 , ,

Nietzsche
()
15 комментариев

Карта фабрик на лямбдах: clang не осилил

Появилась задача: распарсить конфиг и на его основе инициализировать сложную иерахию полиморфных объектов. Можно было накатать простыню if-else на пару страниц или написать генератор этой самой простыни, но я выбрал велосипединг.

Помимо нежелания катать простыню, сложность заключалась в том, что сначала нужно было определить типы создаваемых объектов, и только после этого можно было определить значения аргументов для их инициализации. Подошло решение в виде фабрики на лямбдах с примесью вариативных шаблонов.

Привожу очень упрощенный вариант:

#include <iostream>
#include <memory>
#include <functional>
#include <map>

template <typename TKey, typename TProduct, typename... Args>
struct Factory {

	using Product = std::unique_ptr<TProduct>;
	using Lambda = std::function<Product(Args...)>;
	using Map = std::map<TKey, Lambda>;

	template <typename TConcreteProduct>
	static Lambda create;
};


template <typename TKey, typename TProduct, typename... Args>
template <typename TConcreteProduct>
typename Factory<TKey, TProduct, Args...>::Lambda
Factory<TKey, TProduct, Args...>::create = [](Args... args) {
	return std::make_unique<TConcreteProduct>(args...);
};

struct Base {

	Base(int number, const std::string & message) :
		_number(number), _message(message) {}
	virtual ~Base() = default;
	virtual void print() const = 0;

protected:

	int _number;
	std::string _message;
};

struct First : Base {
	using Base::Base;
	virtual void print() const override {
		std::cout << "First::print() = " << _number << ", " << _message << "\n";
	}
};

struct Second : Base {
	using Base::Base;
	virtual void print() const override {
		std::cout << "Second::print() = " << _number << ", " << _message << "\n";
	}
};

struct Third : Base {
	using Base::Base;
	virtual void print() const override {
		std::cout << "Third::print() = " << _number << ", " << _message << "\n";
	}
};

using SimpleFactory = Factory<std::string, Base, int, const std::string &>;

static const SimpleFactory::Map factoryMap({
	{ "first", SimpleFactory::create<First> },
	{ "second", SimpleFactory::create<Second> },
	{ "third", SimpleFactory::create<Third> },
});

int main() {

	std::cout << "using a specific factory:\n";
	auto key = "first";
	auto factory = factoryMap.at(key);
	auto product = factory(123, "some message");
	std::cout << key << ": ";
	product->print();
	std::cout << "\n";

	std::cout << "test all:\n";
	for(auto & factoryPair : factoryMap) {
		auto product = factoryPair.second(321, "test123");
		std::cout << factoryPair.first << ": ";
		product->print();
	}

}

Код скомпилился, но результат меня сбил с толку. Полночи выискивал багу у себя, а оказалось, что она в компиляторе.

clang 4.0.0-r2: 

using a specific factory:
first: Third::print() = 123, some message

test all:
first: Third::print() = 321, test123
second: Third::print() = 321, test123
third: Third::print() = 321, test123

gcc 5.4.0-r3: 

using a specific factory:
first: First::print() = 123, some message

test all:
first: First::print() = 321, test123
second: Second::print() = 321, test123
third: Third::print() = 321, test123

 , , ,

Nietzsche
()
11 комментариев

Генерирование lookup table в compile-time

Хочется заполнить constexpr std::array на стадии компиляции, но clang 4.0 с флагом -std=c++1z ругается:

non-constexpr function 'operator[]' cannot be used in a constant expression
                lookupTable[i] = f(i);

Какой тогда толк от constexpr std::array, если его нельзя по нормальному использовать?

Начал пробовать по разному и получилось следующим образом:


template <size_t N>
struct CompileTimeLookupTable {

    using TableValue = double;
    using LookupTable = std::array<TableValue, N>;

    constexpr TableValue f(size_t);

    constexpr static auto createLookupTable() {
        LookupTable lookupTable {};
        ...
        const_cast<TableValue &>(static_cast<const LookupTable &>(lookupTable)[i]) = f(i); // <--- смущает этот момент
        ...
        return lookupTable;
    }

    constexpr static auto _lookupTable { createLookupTable() };

};

Это UB или не UB? Как сделать менее костыльно?

 , ,

Nietzsche
()
13 комментариев

Музыкальное пиратство

Сразу скажу, что мне пофиг на копирайт, я его не признаю. Тем не менее я покупаю информационный продукт, если хочу отблагодарить автора (постфактум), или, если считаю его цену приемлемой для покупки вслепую (ох уж эти распродажи), а способ доставки удобным. Один из примеров таких продуктов - apple music, который заманил меня тремя бесплатными месяцами, по истечении которых я решил продолжить платную подписку.

Так вот, мне стало интересно, является ли пиратством скачивание с торрентов музыки, которая мне и так доступна через apple music? Сюда же можно добавить книги, которые я купил в бумажном виде, но в дальнейшем решил читать их на планшете/телефоне.

Не платить же мне дважды? Конечно, копирасты скажут, что платить надо, и лучше трижды! Я понимаю, что юридически, скорее всего, да - я пират. Но как это выглядит с морально-этической стороны?

 ,

Nietzsche
()
122 комментария (стр. 2 3)

Эпических обломов тред

Только что со мной произошел инцидент, который можно сравнить с падением в открытый люк, появившийся из ниоткуда прямо перед шагом от обретения чего-то прекрасного - именно так я себя сейчас чувствую.

Ну, значит, просыпаюсь я среди ночи, чтобы отлить, и вдруг мне в голову приходит гениальное решение задачи, которая мучает меня на протяжении последней недели. Муза спустилась с небес! Мчусь к компу, чтобы сформулировать мысль в виде UML диаграммы (задача из сферы проектирования). Напроектировал целый табун классов, и тут, внезапно Dia исчезает! ... (см. первый абзац поста)

Полез я в журнал, а там: 

kernel: dia[9196]: segfault at 7efcc38bce20 ip 00007efcc1d71a8b sp 00007fff1340e0e0 error 4 in libc-2.23.so[7efcc1cfd000+190000]

Сегфолт произошел после добавления очередного атрибута, коих я до этого добавил около сотни (размазанных по разным классам). Т.е. повторить такое специально, скорее всего, не получится, поэтому и багрепорт писать не о чем.

UPD: пока писал пост, наткнулся на файл в домашней директории - Диаграмма1.dia.autosave. Найти бы и расцеловать того, кто до этого додумался! Только странно, что сохраняется в ~/ - неаккуратно как-то.

 , , , ,

Nietzsche
()
26 комментариев

Странности с sys_clone в андроиде

Понадобилось форкнуть процесс на дейвайсе с андроидом без использования либсишной обертки и тут началось...

Первое разочарование - fork в ядре не реализован, вместо него только clone, который вовсе не тот клон, что в libc, а совсем другой, с другими аргументами, причем порядок двух последних аргументов на некоторых архитектурах отличается. Но, как оказалось, достаточно все забить нулями и дернуть за сиськол. Так и сделал. Накидал тестовый шкриптец:

#include <stdio.h>
#include <unistd.h>
#include <sys/syscall.h>

int main(void) {

	long pid = syscall(__NR_clone, 0, NULL, NULL, NULL, NULL);

	if(pid == 0) {
		puts("child"); fflush(stdout);
		while(1);
	}

	puts("parent");

	return 0;
}

Родитель умирает, дите продолжает жить, все как и ожидалось. Код одинаково работает как на десктопе с интелом, так и на андроиде с армом. Ок, идем дальше.

Полностью избавляемся от libc.

SYS_WRITE	= 64
SYS_EXIT	= 93
SYS_CLONE	= 220

  add x9, sp, (8 * 2)

  ldr x0, =0x000a746e65726150 // Parent
  ldr x1, =0x00000a646c696843 // Child
  stp x0, x1, [x9]

  mov x8, SYS_CLONE
  mov x0, xzr
  mov x1, xzr
  mov x2, xzr
  mov x3, xzr
  mov x4, xzr
  svc 0

  cbz x0, child // if(x0 == 0) goto child;

  mov x8, SYS_WRITE
  mov x0, 1
  mov x1, x9
  mov x2, 7
  svc 0

exit:
  mov x8, SYS_EXIT
  mov x0, xzr
  svc 0

child:
  mov x8, SYS_WRITE
  mov x0, 1
  add x1, x9, 8
  mov x2, 6
  svc 0
loop:
  b loop

Результат: выводится строка Parent, затем родитель мрет, дите мрет вместе с ним, даже не успевая вывести строку Child.

Напрашивается ответ - юзать wait, но в том то и дело, что ждать мне не нужно, задача стоит именно форкнуть и выйти. К тому же сишный код с оберткой syscall() работает так, как мне нужно, поэтому я полез смотреть кишки и вот че там было:


// syscall(__NR_clone, 0, NULL, NULL, NULL, NULL);

 778:	d2801b80 	mov	x0, #0xdc                  	// #220
 77c:	52800001 	mov	w1, #0x0                   	// #0
 780:	d2800002 	mov	x2, #0x0                   	// #0
 784:	d2800003 	mov	x3, #0x0                   	// #0
 788:	d2800004 	mov	x4, #0x0                   	// #0
 78c:	d2800005 	mov	x5, #0x0                   	// #0
 790:	97ffffe0 	bl	710 <syscall@plt>

......

// libc.so

00000000000179b0 <syscall@plt>:
   179b0:	f00005f0 	adrp	x16, d6000 <_DYNAMIC+0x390>
   179b4:	f9400a11 	ldr	x17, [x16,#16]
   179b8:	91004210 	add	x16, x16, #0x10
   179bc:	d61f0220 	br	x17

......

000000000001c100 <syscall>:
   1c100:	aa0003e8 	mov	x8, x0
   1c104:	aa0103e0 	mov	x0, x1
   1c108:	aa0203e1 	mov	x1, x2
   1c10c:	aa0303e2 	mov	x2, x3
   1c110:	aa0403e3 	mov	x3, x4
   1c114:	aa0503e4 	mov	x4, x5
   1c118:	aa0603e5 	mov	x5, x6
   1c11c:	d4000001 	svc	#0x0
   1c120:	b140041f 	cmn	x0, #0x1, lsl #12
   1c124:	da809400 	cneg	x0, x0, hi
   1c128:	5403fb08 	b.hi	24088 <__set_errno_internal>
   1c12c:	d65f03c0 	ret

Т.е. код полностью идентичен, в x8 кладется номер сискола и все аргументы забиваются нулями, но дите не мрет вслед за родителем.

Для чистоты эксперимента накидал еще один шкриптец под x86-64:

SYS_EXIT = 60
SYS_CLONE = 56
SYS_WRITE = 1

	mov $0x000a746e65726150, %rax # Parent
	push %rax
	mov $0x00000a646c696843, %rax # Child
	push %rax

	mov $SYS_CLONE, %rax
	xor %rdi, %rdi
	xor %rsi, %rsi
	xor %rdx, %rdx
	xor %r10, %r10
	xor %r8, %r8
	syscall

	test %rax, %rax
	jz child

	mov $SYS_WRITE, %rax
	mov $1, %rdi
	lea 8(%rsp), %rsi
	mov $7, %rdx
	syscall
	

	mov $SYS_EXIT, %rax
	xor %rdi, %rdi
	syscall

child:
	mov $SYS_WRITE, %rax
	mov $1, %rdi
	mov %rsp, %rsi
	mov $6, %rdx
	syscall
loop:
	jmp loop

Все работает как надо, родитель мрет, дите живет.

Такие дела.

 , , ,

Nietzsche
()
6 комментариев

Помогите вспомнить пароль к криптоконтейнеру

Нашел старый хард с зашифрованным разделом. Последний раз юзал его около 4-х лет назад. Шифровался трукриптом 6.3а. Помню только первые 30 символов пароля, остальная часть в пределах 7 - 8 символов (loweralpha-numeric, не более 2-х букв или цифр подряд, первый символ - буква), т.е. сбрутить было бы реально, если бы не одно но... Алгоритм шифрования был либо AES, либо Serpent, а хешфункцию вообще не помню (их 3 варианта).

В наличии есть видюха 780 ti с 2880 ядрами CUDA и собранный cudaHashcat64.bin, но слабо верится в успех брутфорса, так как придется перебирать 6 вероятных комбинаций алгоритма хеширования и шифрования.

Последние пару дней исследовал нешифрованную часть диска с помощью app-forensics/scalpel в надежде найти хотя бы какую-нибудь зацепку - без результатов.

Наиболее благоприятный сценарий - вспомнить. Надеюсь на рефлекторную память, потому что очень часто пароли могу воспроизвести только пальцами на клавиатуре.

Может быть существуют какие-нибудь психологические техники «вспоминания» забытых паролей? Гипноз?

Где арендовать gpu ферму?

 , , , ,

Nietzsche
()
24 комментария

Лицензия, запрещающая распространение софта в бинарном виде

Хотелось бы запублишить код (сферический в вакууме) под свободной GPL-like лицензией, но с оговоркой, что его нельзя распространять в бинарном виде. То есть конечный пользователь обязан собрать его у себя на устройстве, чтобы иметь возможность пользоваться его бинарной версией без нарушения лицензии. Софт, в котором используются куски моего кода, также должен распространятся под аналогичной лицензией.

Есть такое в готовом виде?

Перемещено leave из development

 , ,

Nietzsche
()
170 комментариев (стр. 2 3 4)

Испортилась планка оперативки

Все началось с того, что я решил пересобрать мир. Сборка пакетов происходит в tmpfs.

Кусок из make.conf, чтобы примерно представить нагрузку:

MAKEOPTS="-j9"
EMERGE_DEFAULT_OPTS="--jobs=3 --load-average=8.1 --keep-going --with-bdeps=y --complete-graph"
FEATURES="assume-digests candy collision-protect -ebuild-locks distlocks fail-clean news nodoc noinfo parallel-fetch parallel-install -ebuild-locks protect-owned sandbox strict -test unmerge-orphans splitdebug"

Процесс прервался через несколько часов. Появились ошибки типа:

blk_update_request: I/O error, dev sda, sector 18612352

Система частично продолжала работать, часть софта отказывалась запускаться из-за ошибок I/O. Первая мысль - посыпался /dev/sda.

Ребутаюсь, чтобы грузануться с live-usb и проверить диск. Не успевает появиться логотип биоса - происходит ребут, и так бесконечно. Открываю крышку системника, замечаю красную лампочку около слотов оперативки. Оставляю только одну планку - система грузится нормально. С /dev/sda проблем нет. Методом тыка была выявлена испорченная планка. Внешне трудно определить какие-либо существенные отклонения из-за радиатора, который на неё надет. Снимать его не спешу, потому что есть шанс найти чек и гарантию. Да и мне это мало что даст, т.к. не спец по расчлененке. Единственное внешнее отличие испорченной планки от остальных - небольшая белая полоска «под» контактами.

Нагуглил, что в некоторых ситуациях может помочь чистка контактов спиртом. Отсюда появляется вопрос - где купить спирт? Когда-то нужен был, но в аптеке не продали. Стоит ли ходить по атекам и искать тех, кто продаст, либо есть места, где его продают без напряга?

 ,

Nietzsche
()
23 комментария

Накидайте идей для велосипедов

Всем привет.

Есть учебная задача - написать свою библиотеку классов на С++. Предметная область - любая. Это должно быть что-то достаточно простое, чтобы справиться за день, а код закопать и никогда нигде не использовать. Интересные для меня области: gpgpu, нейронные сети, обработка естественного языка, всякие сетевые штуки (краулеры, парсеры, боты, етц). Много всего интересного лезет в голову, только чувствую, что любая из «интересных» идей заберет куда больше времени, чем подразумевает задача. Следовательно, нужно выдержать баланс между простотой и интересностью. Хочется быстрее покончить с этапом учебных поделий и перейти к чтению Майерса, Саттера, Александреску и пр.

Буду благодарен за любые идеи.

 , , ,

Nietzsche
()
19 комментариев

Объявления вне пространства имен

Приветствую.

Отрывок из книги Р. Лафоре «Объектно-ориентированное программирование в С++» (611 страница)

Объявления можно помещать и вне пространства имен, и они будут работать, как если бы они были внутри него. Все, что для этого нужно, это имя пространства и оператор разрешения контекста: 

namespace beta
{
	int uno;
}

int beta::dos;

В этом примере и uno, и dos являются объявлениями в пространстве имен beta. 

$ gcc main.cpp
main.cpp:6:11: ошибка: «beta::dos» следовало объявить внутри «beta»
 int beta::dos;
           ^

Кто не прав?

 , ,

Nietzsche
()
15 комментариев

Помогите посадить okular на диету!

Доброго времени суток.

Сегодня совершенно случайно заметил, что okular жрет 16 гигов оперативки, в этот момент была открыта pdf'ка на 40 мегабайт. Стало интересно, захотелось понять причину. Протестировал его на нескольких pdf/djvu разных размеров. Проблема проявлялась во всех случаях. В результате было замечено, что аппетит у очкарика зависит от размера файла, т.е. на небольших экземплярах (2 - 5 мб) кушает в пределах 2 - 3 гб оперативки, на солидных книжищах (~1000 страниц, ~50 мб) сжирает в пределах 15 - 20 гб оперативки.

Не могу сказать, когда это началось, так как внешне на стабильность системы это никак не влияло. Машинка у меня на вырост, 32 кг памяти, а своп хоть и включен, но ни разу не было ситуации (не замечал этого), когда бы он использовался, поэтому и тормозов не было замечено.

Пришла в голову мысль поставить valgrind и посмотреть, что он скажет. Не знаю точно, что нужно делать, так как раньше не доводилось его не юзать, да и вообще нет опыта работы с профайлерами. Просматривая маны, бросилось в глаза два модуля, memcheck и massif. Вот результаты:

valgrind --leak-check=full okular

После запуска okular'а, был открыт pdf файл на 4 мб.

Выхлоп - http://pastebin.com/raw.php?i=20m3TQ2E

Взято из top: 

2542776 1,998g 52848 S   0,0  6,4   0:06.62 okular

Далее был запущен massif и открыт тот же файл на 4 мб: 

valgrind --tool=massif okular

ms_print massif.out.2478

Верхушка лога:

--------------------------------------------------------------------------------
Command:            okular
Massif arguments:   (none)
ms_print arguments: massif.out.2478
--------------------------------------------------------------------------------


    GB
1.919^                                                                       #
     |                                                                     @@#
     |                                                                 @@:@@@#
     |                                                              @@@@@:@@@#
     |                                                          ::@:@ @@@:@@@#
     |                                                       ::@: @:@ @@@:@@@#
     |                                                  @@@::::@: @:@ @@@:@@@#
     |                                               ::@@ @: ::@: @:@ @@@:@@@#
     |                                            ::@::@@ @: ::@: @:@ @@@:@@@#
     |                                         @::: @::@@ @: ::@: @:@ @@@:@@@#
     |                                     :@::@::: @::@@ @: ::@: @:@ @@@:@@@#
     |                                ::@:::@: @::: @::@@ @: ::@: @:@ @@@:@@@#
     |                              @:: @: :@: @::: @::@@ @: ::@: @:@ @@@:@@@#
     |                          ::::@:: @: :@: @::: @::@@ @: ::@: @:@ @@@:@@@#
     |                      @@::::: @:: @: :@: @::: @::@@ @: ::@: @:@ @@@:@@@#
     |                  ::@:@ : ::: @:: @: :@: @::: @::@@ @: ::@: @:@ @@@:@@@#
     |                 :: @:@ : ::: @:: @: :@: @::: @::@@ @: ::@: @:@ @@@:@@@#
     |            ::::::: @:@ : ::: @:: @: :@: @::: @::@@ @: ::@: @:@ @@@:@@@#
     |        @:::: :: :: @:@ : ::: @:: @: :@: @::: @::@@ @: ::@: @:@ @@@:@@@#
     |    ::@@@:: : :: :: @:@ : ::: @:: @: :@: @::: @::@@ @: ::@: @:@ @@@:@@@#
   0 +----------------------------------------------------------------------->Gi
     0                                                                   42.85

Обжористый стек вызовов (взято из начала лога), тут он кушает всего 150 метров:

99.31% (156,626,353B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->95.06% (149,931,100B) 0x6A4D60A: QImageData::create(QSize const&, QImage::Format, int) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| ->94.80% (149,517,876B) 0x6A4D75B: QImage::QImage(int, int, QImage::Format) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | ->94.26% (148,661,288B) 0x6A4E9A1: QImage::copy(QRect const&) const (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | ->78.71% (124,136,496B) 0x6A4F913: QImage::detach() (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | ->78.71% (124,136,496B) 0x6A750C5: QRasterPixmapData::createPixmapForImage(QImage&, QFlags<Qt::ImageConversionFlag>, bool) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | | ->78.71% (124,136,496B) 0x6A75130: QRasterPixmapData::fromImage(QImage const&, QFlags<Qt::ImageConversionFlag>) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |   ->78.71% (124,136,496B) 0x6A66ED0: QPixmap::fromImage(QImage const&, QFlags<Qt::ImageConversionFlag>) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |     ->78.71% (124,136,496B) 0x182BD157: ??? (in /usr/lib64/libokularcore.so.5.0.0)
| | | | |       ->78.71% (124,136,496B) 0x64828BC: QObject::event(QEvent*) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |         ->78.71% (124,136,496B) 0x699935A: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |           ->78.71% (124,136,496B) 0x699FACB: QApplication::notify(QObject*, QEvent*) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |             ->78.71% (124,136,496B) 0x5771568: KApplication::notify(QObject*, QEvent*) (in /usr/lib64/libkdeui.so.5.14.8)
| | | | |               ->78.71% (124,136,496B) 0x646A26B: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                 ->78.71% (124,136,496B) 0x646D488: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                   ->78.71% (124,136,496B) 0x649818C: ??? (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                     ->78.71% (124,136,496B) 0xB2FC552: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4200.2)
| | | | |                       ->78.71% (124,136,496B) 0xB2FC796: ??? (in /usr/lib64/libglib-2.0.so.0.4200.2)
| | | | |                         ->78.71% (124,136,496B) 0xB2FC83A: g_main_context_iteration (in /usr/lib64/libglib-2.0.so.0.4200.2)
| | | | |                           ->78.71% (124,136,496B) 0x649795C: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                             ->78.71% (124,136,496B) 0x6A37674: ??? (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |                               ->78.71% (124,136,496B) 0x6468DFD: QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                                 ->78.71% (124,136,496B) 0x64690F3: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                                   ->78.71% (124,136,496B) 0x646E557: QCoreApplication::exec() (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                                     ->78.71% (124,136,496B) 0x409BDE: ??? (in /usr/bin/okular)
| | | | |                                       ->78.71% (124,136,496B) 0x7788AA3: (below main) (in /lib64/libc-2.20.so)

Этот же стек (в конце лога), но теперь он кушает 2 гигабайта:

--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
 56 46,009,662,363    2,060,416,776    2,057,966,717     2,450,059            0
99.88% (2,057,966,717B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->97.66% (2,012,172,328B) 0x6A4D60A: QImageData::create(QSize const&, QImage::Format, int) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| ->97.65% (2,011,902,528B) 0x6A4D75B: QImage::QImage(int, int, QImage::Format) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | ->97.62% (2,011,368,392B) 0x6A4E9A1: QImage::copy(QRect const&) const (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | ->96.43% (1,986,843,600B) 0x6A4F913: QImage::detach() (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | ->96.43% (1,986,843,600B) 0x6A750C5: QRasterPixmapData::createPixmapForImage(QImage&, QFlags<Qt::ImageConversionFlag>, bool) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | | ->96.43% (1,986,843,600B) 0x6A75130: QRasterPixmapData::fromImage(QImage const&, QFlags<Qt::ImageConversionFlag>) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |   ->96.43% (1,986,843,600B) 0x6A66ED0: QPixmap::fromImage(QImage const&, QFlags<Qt::ImageConversionFlag>) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |     ->96.43% (1,986,843,600B) 0x182BD157: ??? (in /usr/lib64/libokularcore.so.5.0.0)
| | | | |       ->96.43% (1,986,843,600B) 0x64828BC: QObject::event(QEvent*) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |         ->96.43% (1,986,843,600B) 0x699935A: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |           ->96.43% (1,986,843,600B) 0x699FACB: QApplication::notify(QObject*, QEvent*) (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |             ->96.43% (1,986,843,600B) 0x5771568: KApplication::notify(QObject*, QEvent*) (in /usr/lib64/libkdeui.so.5.14.8)
| | | | |               ->96.43% (1,986,843,600B) 0x646A26B: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                 ->96.43% (1,986,843,600B) 0x646D488: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                   ->96.43% (1,986,843,600B) 0x649818C: ??? (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                     ->96.43% (1,986,843,600B) 0xB2FC552: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4200.2)
| | | | |                       ->96.43% (1,986,843,600B) 0xB2FC796: ??? (in /usr/lib64/libglib-2.0.so.0.4200.2)
| | | | |                         ->96.43% (1,986,843,600B) 0xB2FC83A: g_main_context_iteration (in /usr/lib64/libglib-2.0.so.0.4200.2)
| | | | |                           ->96.43% (1,986,843,600B) 0x649795C: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                             ->96.43% (1,986,843,600B) 0x6A37674: ??? (in /usr/lib64/qt4/libQtGui.so.4.8.6)
| | | | |                               ->96.43% (1,986,843,600B) 0x6468DFD: QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                                 ->96.43% (1,986,843,600B) 0x64690F3: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                                   ->96.43% (1,986,843,600B) 0x646E557: QCoreApplication::exec() (in /usr/lib64/qt4/libQtCore.so.4.8.6)
| | | | |                                     ->96.43% (1,986,843,600B) 0x409BDE: ??? (in /usr/bin/okular)
| | | | |                                       ->96.43% (1,986,843,600B) 0x7788AA3: (below main) (in /lib64/libc-2.20.so)

Полный лог massif + ms_print - http://pastebin.com/raw.php?i=irEudVpd

gentoo, qt 4.8.6-r1, poppler 0.32.0, okular 4.14.3

Баг или фича?

 ,

Nietzsche
()
10 комментариев

Проблема с fn-клавишами

Доброго времени суток. Недавно поставил себе дженту с третьим гномом и, соответственно, с systemd. Все работает замечательно, кроме одной небольшой неприятности.

Если после загрузки системы не переподключить клавиатуру (выдернуть шнур и вставить обратно), то функциональные клавиши не работают. В частности, клавиши: prev track (FN + F5), play/pause (FN + F6), next track (FN + F7), отвечающие за контроль плеера (тестировалось на Banshee/Amarok/VLC, т.е. проблема не касается конкретного плеера).

Клавиатура - Razer Deathstalker.

кусок лога из journalctl до переподключения http://pastebin.com/QqZu0C2K (fn-кнопки не работают)

кусок лога после переподключения http://pastebin.com/Cb30LhWF (после чего fn-кнопки работают, как задумано)

часть выхлопа lsusb -v http://pastebin.com/mpq9iB1m

cat /etc/portage/make.conf
...
INPUT_DEVICES="evdev"
....

Штука некритичная, но все же хотелось бы разобраться. Спасибо.

 , , ,

Nietzsche
()
5 комментариев

RSS подписка на новые темы