Mainapp error sigsegv как исправить ошибку

Как исправить ошибку Java Sigsegv (0xb)

Проверка «Java Error Sigsegv (0Xb)»

Как правило, практикующие ПК и сотрудники службы поддержки знают «Java Error Sigsegv (0Xb)» как форму «ошибки во время выполнения». Чтобы убедиться, что функциональность и операции работают в пригодном для использования состоянии, разработчики программного обеспечения, такие как Oracle Corporation, выполняют отладку перед выпусками программного обеспечения. Ошибки, такие как ошибка Sigsegv (0xb), иногда удаляются из отчетов, оставляя проблему остается нерешенной в программном обеспечении.

Пользователи Java могут столкнуться с ошибкой Sigsegv (0xb), вызванной нормальным использованием приложения, которое также может читать как «Java Error Sigsegv (0Xb)». Сообщение об этой ошибке Sigsegv (0xb) позволит разработчикам обновить свое приложение и исправить любые ошибки, которые могут вызвать его. Затем Oracle Corporation исправит ошибки и подготовит файл обновления для загрузки. Если есть запрос на обновление Java, это обычно обходной путь для устранения проблем, таких как ошибка Sigsegv (0xb) и другие ошибки.

Что запускает ошибку времени выполнения Sigsegv (0xb)?

Ошибки выполнения при запуске Java — это когда вы, скорее всего, столкнетесь с «Java Error Sigsegv (0Xb)». Вот три наиболее распространенные причины, по которым происходят ошибки во время выполнения ошибки Sigsegv (0xb):

Ошибка Sigsegv (0xb) Crash — Ошибка Sigsegv (0xb) остановит компьютер от выполнения обычной программной операции. Если данный ввод недействителен или не соответствует ожидаемому формату, Java (или OS) завершается неудачей.

Утечка памяти «Java Error Sigsegv (0Xb)» — ошибка Sigsegv (0xb) утечка памяти приводит к увеличению размера Java и используемой мощности, что приводит к низкой эффективности систем. Потенциальным фактором ошибки является код Oracle Corporation, так как ошибка предотвращает завершение программы.

Ошибка Sigsegv (0xb) Logic Error — логическая ошибка возникает, когда Java производит неправильный вывод из правильного ввода. Это происходит, когда исходный код Oracle Corporation вызывает уязвимость при обработке информации.

Oracle Corporation проблемы с Java Error Sigsegv (0Xb) чаще всего связаны с повреждением или отсутствием файла Java. Обычно, установка новой версии файла Oracle Corporation позволяет устранить проблему, из-за которой возникает ошибка. В некоторых случаях реестр Windows пытается загрузить файл Java Error Sigsegv (0Xb), который больше не существует; в таких ситуациях рекомендуется запустить сканирование реестра, чтобы исправить любые недопустимые ссылки на пути к файлам.

Классические проблемы Java Error Sigsegv (0Xb)

Усложнения Java с Java Error Sigsegv (0Xb) состоят из:

• «Ошибка Java Error Sigsegv (0Xb). «
• «Недопустимая программа Win32: Java Error Sigsegv (0Xb)»
• «Извините, Java Error Sigsegv (0Xb) столкнулся с проблемой. «
• «Файл Java Error Sigsegv (0Xb) не найден.»
• «Java Error Sigsegv (0Xb) не может быть найден. «
• «Ошибка запуска программы: Java Error Sigsegv (0Xb).»
• «Java Error Sigsegv (0Xb) не работает. «
• «Java Error Sigsegv (0Xb) выйти. «
• «Неверный путь к приложению: Java Error Sigsegv (0Xb).»

Проблемы Java Error Sigsegv (0Xb) с участием Javas возникают во время установки, при запуске или завершении работы программного обеспечения, связанного с Java Error Sigsegv (0Xb), или во время процесса установки Windows. Важно отметить, когда возникают проблемы Java Error Sigsegv (0Xb), так как это помогает устранять проблемы Java (и сообщать в Oracle Corporation).

Эпицентры Java Error Sigsegv (0Xb) Головные боли

Большинство проблем Java Error Sigsegv (0Xb) связаны с отсутствующим или поврежденным Java Error Sigsegv (0Xb), вирусной инфекцией или недействительными записями реестра Windows, связанными с Java.

В частности, проблемы с Java Error Sigsegv (0Xb), вызванные:

• Недопустимая (поврежденная) запись реестра Java Error Sigsegv (0Xb).
• Файл Java Error Sigsegv (0Xb) поврежден от вирусной инфекции.
• Вредоносное удаление (или ошибка) Java Error Sigsegv (0Xb) другим приложением (не Java).
• Другое программное обеспечение, конфликтующее с Java, Java Error Sigsegv (0Xb) или общими ссылками.
• Поврежденная загрузка или неполная установка программного обеспечения Java.

Совместима с Windows 2000, XP, Vista, 7, 8, 10 и 11

Источник

Как исправить время выполнения Ошибка Sigsegv (0xb) Ошибка Java Sigsegv (0Xb)

В этой статье представлена ошибка с номером Ошибка Sigsegv (0xb), известная как Ошибка Java Sigsegv (0Xb), описанная как Ошибка Sigsegv (0xb): Возникла ошибка в приложении Java. Приложение будет закрыто. Приносим свои извинения за неудобства.

Информация об ошибке

Имя ошибки: Ошибка Java Sigsegv (0Xb)
Номер ошибки: Ошибка Sigsegv (0xb)
Описание: Ошибка Sigsegv (0xb): Возникла ошибка в приложении Java. Приложение будет закрыто. Приносим свои извинения за неудобства.
Программное обеспечение: Java
Разработчик: Oracle Corporation

Этот инструмент исправления может устранить такие распространенные компьютерные ошибки, как BSODs, зависание системы и сбои. Он может заменить отсутствующие файлы операционной системы и библиотеки DLL, удалить вредоносное ПО и устранить вызванные им повреждения, а также оптимизировать ваш компьютер для максимальной производительности.

О программе Runtime Ошибка Sigsegv (0xb)

Время выполнения Ошибка Sigsegv (0xb) происходит, когда Java дает сбой или падает во время запуска, отсюда и название. Это не обязательно означает, что код был каким-то образом поврежден, просто он не сработал во время выполнения. Такая ошибка появляется на экране в виде раздражающего уведомления, если ее не устранить. Вот симптомы, причины и способы устранения проблемы.

Определения (Бета)

Здесь мы приводим некоторые определения слов, содержащихся в вашей ошибке, в попытке помочь вам понять вашу проблему. Эта работа продолжается, поэтому иногда мы можем неправильно определить слово, так что не стесняйтесь пропустить этот раздел!

• Java — Java не следует путать с JavaScript или JScript — это объектно-ориентированный язык программирования общего назначения, предназначенный для использования вместе с JVM виртуальной машины Java.
• Sigsegv . На POSIX-совместимых платформах SIGSEGV — это сигнал, отправляемый процессу, когда он делает недопустимую ссылку на память или ошибку сегментации.

Симптомы Ошибка Sigsegv (0xb) — Ошибка Java Sigsegv (0Xb)

Ошибки времени выполнения происходят без предупреждения. Сообщение об ошибке может появиться на экране при любом запуске %программы%. Фактически, сообщение об ошибке или другое диалоговое окно может появляться снова и снова, если не принять меры на ранней стадии.

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

(Ошибка Java Sigsegv (0Xb)) Repair Tool»/>
(Только для примера)

Причины Ошибка Java Sigsegv (0Xb) — Ошибка Sigsegv (0xb)

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

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

Методы исправления

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

Если метод ремонта вам подошел, пожалуйста, нажмите кнопку upvote слева от ответа, это позволит другим пользователям узнать, какой метод ремонта на данный момент работает лучше всего.

Источник

Обработка многократно возникающих SIGSEGV-подобных ошибок

Тема изъезжена и уже не мало копий было сломано из-за неё. Так или иначе люди продолжают задаваться вопросом о том может ли приложение написанное на C/C++ не упасть после разыменования нулевого указателя, например. Краткий ответ — да, даже на Хабре есть статьи на сей счёт.

Одним из наиболее частых ответов на данный вопрос является фраза «А зачем? Такого просто не должно случаться!». Истинные причины того почему люди продолжают интересоваться данной тематикой могут быть разные, одной из них может быть лень. В случая когда лениво или дорого проверять всё и вся, а исключительные ситуации случаются крайне редко можно, не усложняя кода, завернуть потенциально падающие фрагменты кода в некий try / catch который позволит красиво свернуть приложение или даже восстановится и продолжить работу как ни в чём не бывало. Наиболее ненормальным как раз таки может показаться желание снова и снова ловить ошибки, обычно приводящие к падению приложения, обрабатывать их и продолжать работу.

Итак попробуем создать нечто позволяющее решать проблему обработки SIGSEGV-подобных ошибок. Решение должно быть по максимуму кроссплатформенным, работать на всех наиболее распространённых десктопных и мобильных платформах в однопоточных и многопоточных окружениях. Так же сделаем возможным существование вложенных try / catch секций. Обрабатывать будем следующие виды исключительных ситуаций: доступ к памяти по неправильным адресам, выполнение невалидных инструкций и деление на ноль. Апофеозом будет то, что произошедшие аппаратные исключения будут превращаться в обычные C++ исключения.

Наиболее часто для решения аналогичным поставленной задачам рекомендуется использовать POSIX сигналы на не Windows системах, а на Windows Structured Exception Handling (SEH). Поступим примерно следующим образом, но вместо SEH будем использовать Vectored Exception Handling (VEH), которые очень часто обделены вниманием. Вообще, со слов Microsoft, VEH является расширением SEH, т.е. чем-то более функциональным и современным. VEH чем-то схож c POSIX сигналами, для того чтобы начать ловить какие либо события обработчик надо зарегистрировать. Однако в отличии от сигналов для VEH можно регистрировать несколько обработчиков, которые будут вызываться по очереди до тех пор пока один из них не обработает возникшее событие.

В довесок к обработчикам сигналов возьмём на вооружение пару setjmp / longjmp , которые позволят нам возвращаться туда куда нам хочется после возникновения аварийной ситуации и каким-либо способом обрабатывать эту самую исключительную ситуацию. Так же, чтобы наша поделка работала в многопоточных средах нам понадобится старый добрый thread local storage (TLS), который также доступен во всех интересующих нас средах.

Самое простое, что необходимо сделать чтобы просто не упасть в случае аварийной ситуации — это написать свой обработчик и зарегистрировать его. В большинстве случаев людям достаточно просто собрать необходимое количество информации и красиво свернуть приложение. Так или иначе обработчик сигналов регистрируется всем известным способом. Для POSIX-совместимых систем это выглядит следующим образом:

Выше приведённый фрагмент кода регистрирует обработчик для следующий сигналов: SIGBUS , SIGFPE , SIGILL , SIGSEGV . Помимо этого с помощью вызова sigaltstack указываться, что обработчик сигнала должен запускаться на альтернативном, своём собственном, стеке. Это позволяет выживать приложению даже в условиях stack overflow, который легко может возникнуть в случае бесконечно рекурсии. Если не задать альтернативный стек, то подобного рода ошибки не возможно будет обработать, приложение будет просто падать, т.к. для вызова и выполнения обработчика просто не будет стека и с этим ничего нельзя будет сделать. Так же сохраняются указатели на ранее зарегистрированные обработчики, что позволит их вызывать, если наш обработчик поймёт, что делать ему нечего.

Для Windows код намного короче:

Обработчик один, он ловит сразу все события (не только аппаратные исключения надо сказать) и нет никакой возможности что-либо сделать со стеком как в Linux, например. Единица, подаваемая первым аргументом в функцию AddVectoredExceptionHandler , говорит о том, что наш обработчик должен вызываться первым, перед любыми другими уже имеющимися. Это даёт нам шанс быть первыми и предпринять необходимые нам действия.

Сам обработчик для POSIX систем выглядит следующим образом:

Надо сказать, что для того чтобы наш обработчик сигналов стал многоразовым, т.е. мог вызываться снова и снова в случае возникновения новых ошибок, мы должны при каждом заходе разблокировать сработавший сигал. Это необходимо в тех случаях, когда обработчик знает, что исключительная ситуация возникла в участке кода, который завёрнут в некие try / catch о которых речь пойдёт позже. Если же аварийная ситуация сложилась там где мы её совсем не ожидали, дела будут переданы ранее зарегистрированному обработчику сигналов, если такового нет, то вызывается обработчик по умолчанию, который завершит терпящее аварию приложение.

Обработчик для Windows выглядит следующим образом:

Как уже упоминалось выше VEH обработчик на Windows ловит много чего ещё помимо аппаратных исключений. Например при вызове OutputDebugString возникает исключение с кодом DBG_PRINTEXCEPTION_C . Подобные события мы обрабатывать не будем и просто вернём EXCEPTION_CONTINUE_SEARCH , что приведёт к тому что ОС пойдёт искать следующий обработчик, который обработает данное событие. Также мы не хотим обрабатывать C++ исключения, которым соответствует магический код 0xE06D7363L не имеющий нормального имени.

Как на POSIX-совместимых системах так и на Windows в конце обработчика вызывается longjmp , который позволяет нам вернуться вверх по стеку, до самого начала секции try и обойти её попав в ветку catch , в которой можно будет сделать все необходимые для восстановления работы действия и продолжить работу так как будто ничего страшного не произошло.

Для того, чтобы обычный C++ try начал ловить не свойственные ему исключительные ситуации необходимо в самое начало поместить небольшой макрос HW_TO_SW_CONVERTER :

Выглядит довольно кудряво, но по факту здесь делается очень простая вещь:

1. Вызывается setjmp , который позволяет нам запомнить место где мы начали и куда нам надо вернуться в случае аварии.
2. Если по пути выполнения случилось аппаратное исключение, то setjmp вернёт не нулевое значение, после того как где-то по пути был вызван longjmp . Это приведёт к тому, что будет брошено C++ исключение типа HwException, которое будет содержать информацию о том какого вида ошибка случилась. Брошенное исключение без проблем ловится стандартным catch .

Упрощённо приведённый выше макрос разворачивается в следующий псевдокод:

У подхода setjmp / longjmp есть один существенный недостаток. В случае обычных C++ исключений, происходит размотка стека при которой вызываются деструкторы всех созданных по пути объектов. В случае же с longjmp мы сразу прыгаем в исходную позицию, никакой размотки стека не происходит. Это накладывает соответствующие ограничения на код, который находится внутри таких секций try , там нельзя выделять какие-либо ресурсы ибо есть риск их навсегда потерять, что приведёт к утечкам.

Ещё одним ограничением является то, что setjmp нельзя использовать в функциях/методах объявленных как inline . Это ограничение самого setjmp . В лучшем случае компилятор просто откажется собирать подобный код, в худшем он его соберёт, но полученный бинарный файл будет просто аварийно завершать свою работу.

Самым ненормальным действием, которое приходится принимать после обработки аппаратного исключения на Windows является необходимость вызова RemoveVectoredExceptionHandler . Если этого не сделать, то после каждого входа в наш обработчик VEH и выполнения longjmp там будет складываться ситуация как-будто наш обработчик был зарегистрирован ещё один раз. Это приводит к тому, что при каждой последующей аварийной ситуации обработчик будет вызываться всё больше и больше раз подряд, что будет приводить к плачевным последствиям. Данное решение было найдено исключительно путём многочисленных магических экспериментов и нигде никак не документировано.

Для того, чтобы решение работало в многопоточных окружениях необходимо чтобы каждый поток имел собственное место где можно сохранять контекст исполнения с помощью setjmp . Для этих целей и используется TLS, в использовании которого нет ничего хитрого.

Сам контекст исполнения оформлен в виде простого класса имеющего следующие конструктор и деструктор:

Данный класс имеет поле prev_context , которое даёт нам возможность создавать цепочки из вложенных секций try / catch .

Полный листинг описанного выше изделия доступен в GitHub’е:
https://github.com/kutelev/hwtrycatch

В доказательство того, что всё работает как описано имеется автоматическая сборка и тесты под платформы Windows, Linux, Mac OS X и Android:

Под iOS это тоже работает, но за неимением устройства для тестирования нет и автоматических тестов.

В заключение скажем, что подобный подход можно использовать и в обычном C. Надо лишь написать несколько макросов, которые будут имитировать работу try / catch из C++.

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

Источник

Модератор: Модераторы

Вернуться в Free Pascal Compiler

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8

30.12.2019C

Bad memory access (SIGBUS) 

Задание такое:
Реализовать вычисления условных арифметических выражений c одномерными динамическими векторами, которые
содержат целочисленные элементы, длиной от 1 до 1000. Эти векторы — объекты своего класса.

Vector.h

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

#ifndef OOP_CLION_VECTOR_H
#define OOP_CLION_VECTOR_H
 
#endif //OOP_CLION_VECTOR_H
 
#include <math.h>
#include <float.h>
#include <conio.h>
#include <iostream>
#include <Windows.h>
#include <string>
#include <iostream>
#include <sstream>
#include <string>
 
using namespace std;
static char *ValueOverflow = "Value overflow exception!n";
static char *IncorrectSize = "Size of the vector is incorrect!n";
static char *DivisionByZero = "Division by zero!n";
 
class Vector {
    friend Vector &operator-(const int a, const Vector &b);
 
private:
    int size;
    int *num;
    char name;
 
public:
    Vector(int size);
 
    Vector(char name);
 
    Vector(int size, char name);
 
    Vector();
 
    Vector (const Vector &initial);
 
    ~Vector();
 
    void showVector();
 
    void inputVector();
 
    char getName() const;
 
    int  getSize() const;
 
    void setSize(int s);
 
    Vector operator-(const int &n);
 
    Vector operator/(const Vector &v1);
 
    const Vector& operator=(const Vector &right);
 
    const Vector& operator=(const int &n);
 
    bool operator==(const Vector &arrInt);
 
    bool operator>(const Vector &arrInt);
 
    bool operator<(const Vector &arrInt);
};

Vector.cpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192

#include "Vector.h"
#include "climits"
#include <assert.h>
 
Vector::Vector(int parSize) {
    size = parSize;
    num = new int[size];
    assert(num!=0);
    for (int i = 0; i < size; i++) {
        num[i] = 0;
    }
}
 
Vector::Vector() {
    size = 0;
    num = 0;
}
 
Vector::~Vector() {
    delete[] num;
 
}
 
void Vector::showVector() {
    for (int i = 0; i < size; i++) {
        cout << "[" << num[i] << "]";
    }
    cout << "n";
}
 
void Vector::inputVector() {
    if (size < 1 || size > 1000) throw IncorrectSize;
 
    num = new int[size];
    for (int i = 0; i < size; i++) {
        num[i] = 0;
    }
    if (size <= 10) {
        for (int i = 0; i < this->size; i++) {
            cout << "Enter Vector " << name << "[" << i << "]: ";
            while (!(cin >> num[i])) {
                cout << "Incorrect input! Please try again." << endl;
                cout << "Enter Vector " << name << "[" << i << "]: ";
                cin.clear();
                while (cin.get() != 'n') { continue; }
            }
            while (cin.get() != 'n') { continue; }
        }
    } else {
        cout << "Vector " << name << " filled randomly!n";
        for (int i = 0; i < size; i++) {
            num[i] = rand() % size;
        }
    }
}
 
char Vector::getName() const {
    return name;
}
 
bool Vector::operator==(const Vector &arrInt) {
    int sumArrInt = 0;
    int sumThis = 0;
    for (int i = 0; i < this->size; i++) {
        sumThis += this->num[i];
    }
    for (int i = 0; i < arrInt.size; i++) {
        sumArrInt += arrInt.num[i];
    }
    if (sumThis == sumArrInt) {
        return true;
    } else return false;
}
 
bool Vector::operator>(const Vector &arrInt) {
    int sumArrInt = 0;
    int sumThis = 0;
    for (int i = 0; i < this->size; i++) {
        sumThis += this->num[i];
    }
    for (int i = 0; i < arrInt.size; i++) {
        sumArrInt += arrInt.num[i];
    }
    if (sumThis > sumArrInt) {
        return true;
    } else return false;
}
 
bool Vector::operator<(const Vector &arrInt) {
    int sumArrInt = 0;
    int sumThis = 0;
    for (int i = 0; i < this->size; i++) {
        sumThis += this->num[i];
    }
    for (int i = 0; i < arrInt.size; i++) {
        sumArrInt += arrInt.num[i];
    }
    if (sumThis < sumArrInt) {
        return true;
    } else return false;
}
 
Vector Vector::operator-(const int &n) {
    Vector tmp(*this);
    for (int i = 0; i < size; i++) {
        long double t = 0;
        t = this->num[i] - n;
        if ((t > INT_MAX || t < INT_MIN) || t != (int) t) throw ValueOverflow;
        tmp.num[i] = (int) t;
    }
    return tmp;
}
 
Vector Vector::operator/(const Vector &v1) {
    int s = 0;
    Vector tmp;
    if (this->size > v1.size) {
        tmp = Vector(*this);
        s = this->size;
    } else {
        tmp = Vector(v1);
        s = v1.size;
    }
 
    for (int i = 0; i < s; i++) {
        if (v1.num[i] == 0) throw DivisionByZero;
        long double t = this->num[i] / v1.num[i];
        if ((t > INT_MAX || t < INT_MIN) || t != (int) t) throw ValueOverflow;
        tmp.num[i] = (int) t;
    }
    return tmp;
}
 
Vector &operator-(int a, const Vector &b) {
    Vector tmp(b.size);
    for (int i = 0; i < b.size; i++) {
        tmp.num[i] = a - b.num[i];
    }
    return tmp;
}
 
const Vector &Vector::operator=(const Vector &right) {
    if (this != &right){
    delete[] num;
    size = right.size;
    num = new int[size];
    assert(num != 0);
    for (int i = 0; i < size; i++) {
        num[i] = right.num[i];
    }
    }
    return *this;
}
 
Vector::Vector(int parSize, char parName) {
    size = parSize;
    num = new int[size];
    assert(num!=0);
    name = parName;
    for (int i = 0; i < size; i++) {
        num[i] = 0;
    }
}
 
void Vector::setSize(int parSize) {
    size = parSize;
}
 
Vector::Vector(char parName) {
    name = parName;
}
 
int Vector::getSize() const {
    return size;
}
 
const Vector& Vector::operator=(const int &n) {
    //if (v != this){
    delete[] num;
    size = 1;
    num = new int[size];
    num[0] = n;
    return *this;
}
 
Vector::Vector(const Vector &initial) {
    size = initial.size;
    num = new int[size];
    assert(num!=0);
    for (int i = 0; i < size; i++)
        num[i] = initial.num[i];
}

main.cpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

#include <iostream>
#include "Vector.h"
 
int inputSize() {
    int inpS = 0;
    while (!(cin >> inpS) || inpS < 1 || inpS > 1000) {
        cout << "Incorrect size. Try again: ";
        cin.clear();
        while (cin.get() != 'n') { continue; }
    }
    while (cin.get() != 'n') { continue; }
    return inpS;
}
 
int main() {
    int esc = 27, key = 0, t = 0, ia, ib;
    Vector *a;
    Vector *b;
    Vector *x;
    do {
        try {
            cout << "---------------------TEST#_" + to_string(++t) + "---------------------n";
            cout << "t 1-b/a tt a>b" << endl;
            cout << "t -10 tt a=b" << endl;
            cout << "t (a-52)/b t a<b" << endl;
 
            *a = Vector('a');
            cout << "Enter size of vector " << a->getName() << " :";
            a->setSize(inputSize());
            if (a->getSize() == 1) {
                cout << "Enter element: ";
                cin >> ia;
                *a = ia;
            } else {
                a->inputVector();
            }
            a->showVector();
 
            *b = Vector('b');
            cout << "Enter size of vector " << b->getName() << " :";
            b->setSize(inputSize());
            if (b->getSize() == 1) {
                cout << "Enter element: ";
                cin >> ib;
                *b = ib;
            } else {
                b->inputVector();
            }
            b->showVector();
 
            *x = Vector('x');
 
            if (*a == *b) {
                cout << "a and b is equal!" << endl;
            } else if (*a < *b) {
                cout << "a is smaller than b!" << endl;
            } else if (*a > *b) {
                cout << "a is bigger than b!" << endl;
            }
 
            if (*a > *b) { *x = 1 - (*b / *a); }
            else if (*a == *b) { *x = -10; }
            else { *x = (*a - 52) / *b; }
            x->showVector();
 
            delete &a, &b, &x;
 
            cout << "Press Esc to exit or any other key to continue...n";
            key = _getch();
        }
        catch (char *message) {
            cout << message << endl;
        }
        catch (...) {
            cout << "Handling unexpected exception..." << endl;
        }
    } while (key != esc);
    return 0;
}

В коде переопределения присваивания для двух векторов на строчке num[i] = right.num[i]; выдаёт ошибку SIGSEGV(Segmnetation fault), при этом программа вылетает с этой ошибко практически сразу же после запуска, т.е. сразу после того, как в консоль выведет решаемый пример. Я никак не могу понять из-за чего так происходит и почему именно здесь.

1
2
3
4
5
6
7
8
9
10
11
12

const Vector &Vector::operator=(const Vector &right) { //right: const Vector &
    if (this != &right){
    delete[] num;
    size = right.size;
    num = new int[size];
    assert(num != 0);
    for (int i = 0; i < size; i++) {
        num[i] = right.num[i]; // i: 46920
    }
    }
    return *this;
}